On Nov 19, 2009, at 7:14 AM, Mike Orr wrote: > 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.
It's not just the lack of documentation. It does things downright.... weird. It's also pretty much unmaintained. Sure, patches will be applied usually, but other than that, its 'done'. For better or worse. It does tons of things in odd ways, writing my own validators never feels quite right, and I still have no clue why its so incredibly painful to write a FancyValidator, or even what a partial validation is. I'm also not a fan of having to catch exceptions just to find out a form is invalid. Why can't I just ask it if its valid or not? It makes my controller code more annoying to write than if I was using WTForms or django-forms as well. Overall though, I really just don't understand how FormEncode works, and not having any docs that kindly explain it with examples, when/how to use partial validation, what class attributes do I need in my own custom validators for each, etc. makes it painful. Ideally, I'd like a simple widget extension system perhaps similar to django-forms that lets me provide basic blocks that spit out what I want, as I find the way TW handles 'resource injection' to be way too overbearing (I want to place the CSS and JS *exactly* where I want them damn it! Please not more middleware!!). I like the django-forms and WTForms have the 'use what you want' approach of letting the entire form be generated, or you can generate just individual elements of it. With TW, its all or nothing it seems. I'm either using Webhelpers for parts of the form, or I try and generate it all. And of course, its a pain to override TW widgets, while its quite easy in django-forms or WTForms. But I also agree with what Ian wrote on the form threads, where things can become kind of sucky when validation and form generation get too tied up. > 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 Doesn't any form lib have to validate a dict to handle the request params dict? > 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. Now, at the same time, I need a lot of the power of FormEncode that the others don't seem to have. Like partial validation, which I think I've needed in the past, but could never figure out how to use as there's no docs on it. ;) I think your goal of increasing the docs for FE will help a lot, I'm talking with Chris Perkins about ways TW2 can make it friendlier to make forms with FE schemas and validators as I'm not a fan of many things TW does at the moment. Also on a side-note, I'm starting to really wonder if there's any point in trying to change @validate before 1.0 or if we should just release 1.0 now with the legacy removal stuff and the few bugfixes that have come up since 0.9.7. Changing @validate now would break a ton of code for 1.0. Maybe rather than fix @validate, we should consider deprecating it entirely post-1.0 and move to a more declarative style since specifying 10 keyword options to a validator looks god-aweful anyways. Thoughts on that? Cheers, Ben -- 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. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=.
