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" <scot.hac...@gmail.com> 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 django-users+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@googlegroups.com. > 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 django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. 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.
