Maybe an example is in order to explain my point further: class Base: name slug created_at created_by ... content_type = models.ForeignKey(ContentType) object_id = models.PositiveIntegerField() content_object = models.GenericForeignKey()
class Product: base = models.ForeignKey(Base, edit_inline=models.STACKED) price weight ... Now if I were to create a new Product object in the admin, I would get all the fields of the Base class and the additional fields from the Product class. When saving a product a Base object and a Product object get created and linked to each other. Granted, this is a very simple implementation of model inheritance and wouldn't be a good performer seeing as no joins can be made. I still think this would make a great addition to the admin contrib and would be useful to a lot of us out there. Comments / Advice / +1 / -1 / ... would be appreciated Regards, Simon On Feb 12, 4:47 pm, "simonbun" <[EMAIL PROTECTED]> wrote: > I'm wondering how hard it would be to build this kind of reverse > edit_inline functionality into the admin contrib. It would open up > some basic model inheritance possibilities if used in combination with > generic relations. > > Personally I've not yet ventured into the django core libraries. Can > anyone with more experience tell me if this is doable or not? I'm > willing to put in some work to get this implemented, but would > appreciate a push in the right direction of course. > > Thanks, > Simon > > On Feb 2, 8:04 pm, "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 toeditthe 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. > > > 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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
