Nested Inlines, dynamic forms, templates and all sorts of problems.

7 views
Skip to first unread message

Felix Ingram

unread,
Oct 9, 2007, 12:11:26 PM10/9/07
to django...@googlegroups.com
Hello all,

I've been making great strides with my application since returning
from the land of Pylons. Given that the app is all about data entry
I've taken the customise-the-admin-app approach to things and made the
switch to newforms-admin this morning.

So far things are working: data is being entered and I've even got
things rendering into ODT and DOCX.

I've now got a little stuck, however. I have three models: Report,
Section and Pictures. Sections are pieces of boilerplate which are
added to a report and pictures are added to a section. Currently
sections are edited inline with reports and pictures are edited inline
with sections.

What I would like to do is allow users to add sections and pictures to
a report at the same time (effectively nested inlines).

In models:

class Report(...):
....fields...

class Section(...):
report = ForeignKey(Report, ...)

class Picture(...):
section = ForeignKey(Section, ...)

I'm trying to decide on the best way to do this. I've come up with a
few possible options and would appreciate any pointers about which
would be the best (or worst).

1. Create a dynamic newform.
This way gets all of the required fields onto the screen but I'd like
to be able to group things in fieldsets and do non-simple layouts. I
tried to create a template but ran into trouble as I didn't know the
number of fields or how to test the name of the fields being looped
over in order to group them.

2. Create the template by hand.
I can just pass my report instance to the template and create the form
manually but then I lose the magic of validation (which would probably
mean I'd end up using formencode or similar).

3. Add a pop up to the current template.
This would allow the user to create the section and then open a pop up
to do the pictures. There are problems with ensuring the section is
valid and saved first, however.

4. Mystery fourth option that I should have been using all along.
I don't know much about this one; anyone any ideas?

If any one's had to implement something similar then I'd appreciate
any advice. Any thoughts or ideas would also be gratefully received.

Regards,

Felix

yml

unread,
Oct 9, 2007, 4:11:48 PM10/9/07
to Django users
Hello Felix,
In a very similar situation I have chosen option 2 for the following
reasons:
* the code was much more simple, at least simpler to maintain for me
* Very hight control on the layout of the form.

I have taken this decision after spending several days working on a
"newform" based solution. And just for the record the newform solution
was working fine but was more complex to maintain/debug.

Regards,
--yml

F.Ingra...@gmail.com

unread,
Oct 10, 2007, 6:01:14 AM10/10/07
to Django users
Hi yml,

On 9 Oct, 20:11, yml <yann.ma...@gmail.com> wrote:
> In a very similar situation I have chosen option 2 for the following
> reasons:
> * the code was much more simple, at least simpler to maintain for me
> * Very hight control on the layout of the form.

Thanks for the reply. I think I'll do likewise; I realised that I can
still use newforms fragments for validation.

Regards,

Felix

Reply all
Reply to author
Forward
0 new messages