On Fri, Oct 23, 2009 at 4:44 PM, Ian Wilson <[email protected]> wrote: > > I think validate was created as a simple yet incomplete solution but > people expect it to do everything.
Yes. I think it was created because TurboGears had a validate decorator and we wanted one too. It solves the use cases it was designed for, but not the ones it wasn't. I don't know how other frameworks, which are generally more rigid than Pylons, work around these use cases. How do TurboGears users handle edge cases in validation? > 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. What specific improvements? Ask and ye may receive. Don't ask and you definitely won't. > 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. Maybe. We'd need to consider a concrete example of the "tools" or design patterns to judge their feasability. Some people use Mako def's to layout a widget with its label and error message and other goodies. Mako's call-with-content feature is good for plugging some (custom) HTML inside other (boilerplate) HTML. > So some comments with regard to what I think such a virtual framework > would need to allow for: These are the design patterns, I suppose? > 1. the separation of form prompt(initial display), form > redisplay(errors) and form rendering(shared by initial display and > redisplay). What would that gain you? Are you talking about something like a class with methods for these three parts? > 2. ability to remove field defaults from being redisplayed (ie. passwords) This would probably have to be done at the controller level, zapping any data values you don't want to redisplay. A form-framework class could have a .zap-these-fields method. > 3. A dummy state class that can be used with formencode FormEncode's 'state' assumptions need to be documented. Ian once remarked he wished 'state' had defaulted to something else rather than None; I don't remember if it he'd wanted an empty dict or object. How would a dummy state object help? > 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. I'm not aware of any encoding changes in FormEncode, but there may have been. There were some bugs with Routes and Unicode arguments, but that's another thing. > 5. How to handle repetitions in the template, schema and error handling That's what the ForEach validator is for, but it's undocumented. I've never gotten the hang of repeating form widgets, so I avoid them. If somebody who understands them can write a howto for putting a repeatable row of widgets on a form and validating them, that would be very helpful. > 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. My understanding of Javascript is basic so I'll skip these. > 8. How to manually raise errors in such a way that the form is > redisplayed as if the FE schema didn't succeed. This needs to be documented in any case. > 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? What kind of "options" do you mean? There are SELECT options, validator constructor args, etc. -- Mike Orr <[email protected]> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
