Marty Alchin a écrit : > On 11/7/07, David Larlet <[EMAIL PROTECTED]> wrote: > >> Unfortunately, what happens with my Form is exactly what I'd like to do: >> create a generic form from a Form class which define fields (with >> widgets, etc) and methods and which is initialized with the content of >> the instance. That seemed more natural to me instead of dealing with >> fields, form and eventually form_for_fields... I know that those >> functions are just shortcuts but it works very well in terms of >> genericity and my main concern here is to integrate a generic way to >> handle forms for resources in restapi. >> > > Well, from what you posted before, your forms aren't really all that > "generic", so I'm not sure exactly what you're trying to accomplish. > Ok, my previous example is really basic to extract the issue but I need to explain the background now.
restapi [1] let you define resources which match a queryset. Those resources are python class (just read at the 5 steps on the homepage of the project to understand it well). When a request is done to the url, the class call the __call__ function and dispatch this one to the right function given the HTTP verb (to sum up). Now let's focus on the form part. The python class (Collection) can be instantiated with a form_class argument which is used in all functions that require form_for_* and this is a key element here. You can have a look at the bottom of the responder file [2] to see what I mean. I didn't know that a BaseForm was required here when I'd proposed to add this argument [3] and I thought that it was a good way to have a generic form which can be customized. Since your previous email, I'm a bit confused about that because I realize that it's a bit useless if I can't get my forms from instances rendered with instances' data. I hope this is more clear now (even if my english is not that good...). [1] http://code.google.com/p/django-rest-interface/ [2] http://django-rest-interface.googlecode.com/svn/trunk/django_restapi/responder.py [3] http://groups.google.com/group/django-developers/browse_thread/thread/f86bd8ea6579baaa/709fdf8e092084ea?lnk=gst SmileyChris a écrit : > On Nov 8, 4:30 am, "Marty Alchin" <[EMAIL PROTECTED]> wrote: > >> When you pass in a subclass of Form, it's already got its fields in >> the right place, but more importantly, it triggers that syntax >> checking again, where it looks for new fields. It basically copies >> fields from a parent class, then adds in the fields that it found in >> the new class. However, since form_for_model and form_for_instance >> don't supply any fields that way, all it gives the new form is what it >> found in the parent class, completely overwriting the fields it got >> from form_for_*. >> > > Actually, I see no good reason why you shouldn't be able to use a Form > as the SuperClass of your form_for_* form. > > I've just attached a patch to #3815 which makes it work. > > Did this patch populate form fields with instance data? I can't figure out this given the tests. Regards, David PS: RajeshD let me know if you're on this list, otherwise I'll forward this email to you, I don't want to cross post anymore. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
