On 02/02/07, jfagnani <[EMAIL PROTECTED]> wrote:
>
> I've been using Django for a few months now and have recently started
> looking into newforms. I was hoping that it would solve some issues I
> was having with the old Manipulator/FormWrapper way, but one thing is
> still a little painful to do when it seems like it could be handled
> automatically.
>
> I have an Order table, which for the most part is setup how you would
> expect: fields for order_number, date, customer, etc. Then there's the
> OrderLineItem model with a ForeignKey field to Order. Again pretty
> standard.
>
> Where the situation deviates is with addresses. I have an Address
> model that I use for addresses all over my application (not just in
> orders). Orders have three addresses: billing, shipping, and
> third_party_billing. So I've created 3 foreign key fields for them
> (with unique related_names, of course).
>
> This issue is that I want to edit the addresses with the order, so the
> edit_inline argument doesn't work for me. I also don't want to add a
> field to Address to relate it to Order, since I use Address in other
> places.
>
> What I lose is the ability to use form_for_model() in a nice way. I
> think a great addition to models and newforms would be a way to model
> what I'm doing and still get the scaffolding features.
>
> That doesn't seem like it'd be too difficult.
>
>
> Barring that, another solution is to add fields to the form returned
> by form_for_model(), then remove them from clean_data so there's no
> exception on form.save(). This is probably what I'll do, but it seems
> unnecessarily tedious. Something that would help there would be
> fieldsets. Then form.fields['shipping_address'] could be a fieldset.
> Maybe even better would be something like
> form.fields['shipping_address'] = form_for_model(Address). This
> subform could validate and save to the database and return the primary
> key for saving the parent form.

Sorry, I had some trouble understanding your situation. So I'm not
sure, but isn't this what prefixes are for? I suppose they're a bit
tedious to use (what with having to inject the id of the child row
into the clean_data of the parent row and shoving the whole thing into
a transaction) but not that bad. I've got some somewhat non-trivial
code involving four interrelated objects being added that isn't really
open but I could possibly share if you're having problems.

Or is it to do with the scaffolding and things not appearing in the
right order? The point in scaffolding is that it was only made to be
knocked down.

>
>
> Well, I'm interested in see what the developers have to say. Do my
> thoughts make sense here? Would these things be difficult to add?
>
> Thanks,
>   Justin
>
>
> >
>


-- 
http://grimboy.co.uk

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to