On Sunday, June 6, 2010, Jason Beaudoin <jasonbeaud...@gmail.com> wrote: > On Fri, Jun 4, 2010 at 2:42 AM, Russell Keith-Magee > <russ...@keith-magee.com> wrote: >> On Fri, Jun 4, 2010 at 12:03 PM, Jason Beaudoin <jasonbeaud...@gmail.com> >> wrote: >>> Silence usually implies some key piece of documentation was missed, or >>> was this just lost amongst more interesting posts? :) >> >> You've missed two important alternatives: >> * The people who can answer your question are busy >> * Nobody can understand your question. >> >> Personally, I fall into both these categories. I'm still trying to dig >> myself out from tasks stemming from DjangoCon; and I really can't work >> out what it is you're trying to do. > > You are fantastic :) > My apologies, let me try to clarify: > > - I've got a model that defines "submissions", which are incoming > messages from HTML forms on various websites and are fielded by admins > - each submission has a bunch of basic information related to the > submission (where, when, etc), as well as the data submitted by the > user (form input field) > - each form on each website is different, and will be different in the future > - allowing non-developers the ability to manage these forms would be > really nice, so creating them through a frontend interface (as opposed > to developers hardcoding forms) is a desirable goal > - the idea is that users would submit information from various source > websites to a central repository via a number of forms all with > different fields and varying in # of fields, field names, etc. the > central repository is a place where everything is reviewed, where > submissions are displayed in a "this is when it came in, from here, > and this is what the user gave us" type of way. > > > I'm not sure how to save the form information with each submission, > given that each form will be different.. I'm used to defining specific > forms and only accepting specific information.
In the normal mode, Django forms are designed to be statically defined by the developer, and then displayed to the user. However, they can actually be dynamically generated during runtime. The most common use case for this that I have seen is to modify the default fields to make the list of choices presented by a ChoiceField change dynamically based upon some request-based property (like the current user). However, you can use the same capability to add completely new fields to the form - you just need to add to form.fields in the constructor of the form. That leaves the problem of deciding how to determine which extra fields Need to be added to the form. This will require some meta-programming on your part - essentially, defining a data model for defining data models. I can't say think of any obvious good examples of this that I can point you at; so a little experimentation will be required on your part. However, if you do it well, you may find that it is a good candidate for a reusable application: something you can build as a standalone capability that you can share with the community for others to use if they find themselves in a similar situation. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
