On Fri, Oct 23, 2009 at 3:58 PM, Kevin J. Smith <[email protected]> wrote: > Thanks for the clarification, Mike. So it is really an issue with the > decorator rather than FormEncode as a whole, correct? As I mentioned, I > have never ran into issues with FormEncode but I have only just started > using Pylons therefore haven't ran across a huge number of cases with the > decorator. > > 2009/10/23 Mike Orr <[email protected]> >> >> On Fri, Oct 23, 2009 at 3:29 PM, Kevin J. Smith <[email protected]> >> wrote: >> > I'm curious as to what everyone's hate for @validate is. I have been a >> > long >> > time user of FormEncode and new to Pylons and found @validate pretty >> > damn >> > slick. I've got custom validators and chained validators and never >> > really >> > had a complaint. I've definitely ran into situations that have me >> > scratching head as to how I am going to get it to work but there always >> > seems to be a way and it ends up being reasonably elegant with >> > FormEncode. >> >> The decorator works, it's just limited. Ideally you want to do all >> your validation the same way. But @validate can only handle some >> cases. >> >> 1. If you want to validate based on the current database record, that >> isn't known until the middle of the action. This would be a good use >> for 'state', but there's no way to pass state through the decorator. >> >> 2. The default post_only=True, on_get=False is ridiculous. It ends up >> passing GET requests through without validation, which will then cause >> your action to crash (if expected data isn't there or is the wrong >> type) or to perform an action it shouldn't. >> >> 3. If the validation passes but you later want to flag a different >> error, you're in the same situation the OP is in. >> >> 4. If you want to perform some of the error handling in the action, >> you can't just paste code from @validate because it does a lot of >> other stuff to deal with its arguments, and you have to sit there and >> think about which parts of the code are relevant to the situation and >> how to transform them. >> >> -- >> Mike Orr <[email protected]> >> >> > > > > -- > Never take life seriously. Nobody gets out alive anyway. > > > > Hey everyone,
I think validate was created as a simple yet incomplete solution but people expect it to do everything. This causes confusion. Once you have any sort of complexity you have to start doing validation manually which is kind of OK except no one has any really good examples and its a ton of boiler plate. I think the biggest problem with formencode, validate and the whole paradigm of validation is that there really is no great domain for examples to be placed in. Other people have built up these well partitioned components(or tried to) as Ian Bicking describes here [1] but there is no framework to really say this is how they should/can/may fit together. And when more components are made its not clear where they go so that other people can find them and extend them. Its not really formencode's thing and its not really a pylons' thing. I will mention though that I think formencode's validators and htmlfill are part of the solution although maybe they themselves need some improvements. Anyways I think this can be solved with some incredibly well documented examples and some more tools in webhelpers. The examples should be tied to specific versions of specific libraries that webhelpers may or may not actually depend on, like mako and pylons for example. Sort of like a web based form processing manual but with a name that isn't horrible. To find out what those tools are I think we should _talk_ about the most generic framework for form validation possible using formencode validators and htmlfill with mako and pylons but not actually design such a framework as much as design the tools for the framework. As it evolves we can build better examples and better helpers. Fitting javascript in all this is a different problem alltogether. For example if you want to create a list of users that you can sort, add and remove BEFORE posting to the server, how does everything fit together? I've created code for this and its not very pretty but I think its the right idea. Yet everytime I try to extend it I have to review every little detail so that I don't mess it up which leads me to believe a tool or an abstraction is missing here as well. So some comments with regard to what I think such a virtual framework would need to allow for: 1. the separation of form prompt(initial display), form redisplay(errors) and form rendering(shared by initial display and redisplay). 2. ability to remove field defaults from being redisplayed (ie. passwords) 3. A dummy state class that can be used with formencode 4. How to pass in the proper encoding, these seems to have changed since some form examples were put in the wiki and I don't understand why some are more complicated than others. 5. How to handle repetitions in the template, schema and error handling 6. How to handle javascript and repetitions 7. How can non-javascript be safely handled when a form is dynamically built with javascript callbacks? For example updating a form's layout depending on the type of user to create. 8. How to manually raise errors in such a way that the form is redisplayed as if the FE schema didn't succeed. 9. How are options used in the form? How can the validators use these options to validate the form? How can they be used to validate AND redisplay the form on error without multiple db requests? [1] http://blog.ianbicking.org/on-form-libraries.html Sorry this email has gotten so wordy. -Ian Wilson --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
