---------- Forwarded message ---------- #405: [Patch] Split up @validate Comment(by Ben Bangert):
I'm rather tempted to go with Marcus's idea: http://marcuscavanaugh.com/posts/pylons-django-forms/ Though of course it kind of sucks to need Django as a dependency just to do forms. I do like the idiom it uses (I've used the same idiom in the past with FormEncode, but its messier), and FormEncode does seem to be getting a bit crufty. Course, I like that FormEncode sticks to one thing, and does it... mostly well (is there any docs anywhere on how the hell to write fancy validators vs partial validators, etc???). Maybe get the django.forms stuff forked off of Django? Would Marcus be up for maintaining just a django.forms fork? ;) -- Ticket URL: <http://pylonshq.com/project/pylonshq/ticket/405#comment:9> === End forward Interesting. So if the boss is questioning FormEncode, I guess we'd better decide which way to go. Writing a FormEncode manual is next on my plate after the WebHelpers docs. I't'll cover the missing pieces: when to use schema, how to use validators with a framework, how to write a FancyValidator with advanced features (although I don't really understand ForEach), and documenting the undocumented validators and which ones are worth using. I wish Sphinx didn't take forever to make all the WebHelpers docstrings consistent, and make the layout complementary between projects. That's what's mainly bogged me down. I wrote earlier about @validate vs WTForms vs django-forms. http://groups.google.com/group/pylons-discuss/browse_thread/thread/2e88433546d97410/cf74daf7c3417c8f?lnk=gst&q=wtforms#cf74daf7c3417c8f http://groups.google.com/group/pylons-discuss/browse_thread/thread/b2762d57ef33be0b/4050e4b1a9762e8b?lnk=gst&q=wtforms#4050e4b1a9762e8b WTForms works similar to django-forms but is standalone. I initially supported it, but there are some things FormEncode does that it doesn't (e.g., validating the configuration dict), and other things people may be using that we don't know about. Plus WTForms would make the form helpers arguably redundant... we'd have two ways to do it. So while I think it may have been good to start with that approach in Pylons, I'm not sure changing the form libraries would be a good idea at this point. The biggest needs seem to be: 1. An alternative to @validate. There are some patches in the ticket. Going to a one-method approach (form display and processing in the same controller action) would also simplify things. 2. Document the undocumented parts of FormEncode. 3. Add an alternate resource route to Routes, that uses the one-method approach. -- Mike Orr <sluggos...@gmail.com> -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-de...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=.
