Re: django.contrib.formtools: High-level abstractions of common form tasks
Hi,
I'm Ben's (Afternoon) collegue Tom,
As much as I was asked to be interesting, I don't do interesting, or at
least when I do, people fall asleep
http://www.halfapenguin.com/djmultipartform.tar.gz
I've posted the code sample on my server, its not complete, but it is a
snapshot of where we are going.
Currently it stores both fields and files.
The form should be constructed using a query dict fed into the url in
as in the following snippet
from myforms import FormWithSections
urlpatterns+= patterns('',
(r'^testmultipartform/((?P\w*)/)?$',
'djmultipartform.views.index',{'manipulator_constructor':
FormWithSections}),
)
(with tabs in the right places of course).
I'll put up a further post with more details about what will be done in
the future to finish it.
Enjoy
From
Tom
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: django.contrib.formtools: High-level abstractions of common form tasks
One slight modification, there was debugging code left in, which I've now fixed. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Have a look at django.newforms
One issue i have with new forms is that there is no detail/description space for the forms, it would be really useful, since at the moment, rather than being able to use the automatic generation methods, i have to write custom templates for each form with the labels in (or use an ugly hack to pull the information in). Adrian Holovaty wrote: On 12/5/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > Adrian Holovaty wrote: > > This is an interesting problem. That template fix would be OK by me, > > but it's sort of a hack. I think we're going to run into similar > > issues with Form.__str__() returning a Unicode object. Maybe, as you > > suggest, Form.__str__() should return a bytestring according to > > DEFAULT_CHARSET, and we could add a Form.__unicode__() that would > > return it as Unicode. > > +1 > > This will work until unicodification when we could get rid of __str__ > version because the whole template will be processed as unicode anyway. OK, I've made the change in newforms [4163]. I also applied Gabor's patch to make the template system handle objects whose str() returns a Unicode object with non-ASCII characters [4161]. This is coming along nicely! Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: django.contrib.formtools: High-level abstractions of common form tasks
Right, after a bit of black magic, a few false starts and a fair bit of reworking, djmultipartform is actually working as its meant to more than just an abstract concept which i posted last time. www.halfapenguin.com/djmultipartform-0.1.tar.gz www.halfapenguin.com/djmultipartform-0.1.zip (in case someone doesn't have the tools to unzip tar.gz). There have been a few changes in the way the system works. there is now a complete method which is accessed through the /complete (overidable when implementing a multipartform), this should be implemented as complete_action. Each page descriptor can have assigned a method to generate a view, which has passed in the the slug, the_form request, and the filter variable. This updates the info_dict passed to the template, by default the method passes an empty dict Stored files can be deleted by a post request to the page with a fieldname and the post variable 'delete' (which should be the fieldname). When a file is uploaded into the store where there is a file already for that field, the old file is deleted and the new file is saved Clear_store now exists and will clear out all the data in the datastore, this should be run as part of the complete method. It is now possible to go backwards without completing form data, however should there be errors in validation of the data on the current page, to avoid confusion the new data for the page will be junked --see below Future work adding in behaviour options for the multipartform with respect to moving backwards and junking data Modularise the view code so that components of the view can be overridden. updating the code to use newforms instead of manipulators --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: django.contrib.formtools: High-level abstractions of common form tasks
Right, after a bit of black magic, a few false starts and a fair bit of reworking, djmultipartform is actually working as its meant to more than just an abstract concept which i posted last time. * www.halfapenguin.com/djmultipartform-0.1.tar.gz * www.halfapenguin.com/djmultipartform-0.1.zip (in case someone doesn't have the tools to unzip tar.gz). There have been a few changes in the way the system works. 1.there is now a complete method which is accessed through the /complete (overidable when implementing a multipartform), this should be implemented as complete_action. 2. Each page descriptor can have assigned a method to generate a view, which has passed in the the slug, the_form request, and the filter variable. This updates the info_dict passed to the template, by default the method passes an empty dict 3. Stored files can be deleted by a post request to the page with a fieldname and the post variable 'delete' (which should be the fieldname). 4.When a file is uploaded into the store where there is a file already for that field, the old file is deleted and the new file is saved 5.Clear_store now exists and will clear out all the data in the datastore, this should be run as part of the complete method. 6. It is now possible to go backwards without completing form data, however should there be errors in validation of the data on the current page, to avoid confusion the new data for the page will be junked --see below Future work * adding in behaviour options for the multipartform with respect to moving backwards and junking data * Modularise the view code so that components of the view can be overridden. * updating the code to use newforms instead of manipulators --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
