I don't know if I'm off target but..... I'm presently work on something like this where I have have to save three models at a go. One model is a stand alone while the other two have a foreign key to the stand alone model which is a many to one relationship. So to implement the many to one where I can save many of the dependent models together with the standalone models, I made use of inline formset and no problems thus far. On Apr 8, 2016 5:16 PM, "Scot Hacker" <[email protected]> wrote:
> I need to build a pretty complex / non-standard form and am looking for > advice on the overall architecture. Consider the following models: > > class UserProfile(User): > ... standard set of fields > > > class ProfileExtra(): > ForeignKey(UserProfile) > extratype (e.g. skill, work experience, website, publication, etc.) > ... another set of fields > > > The idea is that, when editing a profile, a user can add an unlimited > number of these ProfileExtras to their profile. So a user might end up with: > > Profile > name > title > about > photo > Skills > skill 1 > skill 2 > Publications > pub1 > pub2 > pub3 > Jobs > job1 > job2 > > > etc. When editing their profiles, they'll be able to add/edit/delete any > of these *in place* without leaving the page (it'll be ajax.) > > So we have one core model and "n" number of related models. Obviously, a > standard ModelForm can't encompass all of this cleanly. There are several > things about this that just don't mesh well with Django's forms library. It > deals with multiple model types, it deals with unknown additional numbers > of a related model, it needs to be all ajax. > > I'm really not sure about the best way to put it all together. I'm > thinking we probably won't use Django forms at all - just do standard JS to > create/destroy html form inputs on the page dynamically. Consider the whole > thing as one big form element, and it all gets submitted every time. In the > receiving view, pull apart the POST request and process it all manually. > Advantage: total control. Disadvantage: we lose all the magic provided by > model and modelform validation. > > Another thought is that we could make e.g. "skills" into a single field > and use ArrayField (we're on postgres) to store all of the related skills. > Need to experiment with that. > > Have any of you solved a similar problem? Are good ways to meet the > requirements while still being able to take advantage of Django form > validation goodness? I'm all ears. Thanks. > > ./s > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/django-users. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/9a14486b-c7fc-4a99-a0b0-03774c04ae1e%40googlegroups.com > <https://groups.google.com/d/msgid/django-users/9a14486b-c7fc-4a99-a0b0-03774c04ae1e%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2BWjgXN2uJ5yrPuGahV%3D0_yVYHgHspswoZyUaEhv6k6oTy_-ug%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
