I'm going to keep this thread alive. I ended up using the containers class you mentioned. I think my solution is _really_ similar to Tycon's solution as mentioned in the splitting validate ticket except I don't use decorators. Somehow I did not see his solution until I saw that ticket (http://pylonshq.com/project/pylonshq/ticket/405).
First off a couple of things. Some weirdo stuff that is in validate should probably be in here, something like merging str/unicode params and str/unicode forms etc. Or maybe not, a bunch of stuff in validate I think should just stay in validate but I'm no library writer. I've been using this code inside a project for a month now and its been going pretty well although it has all been for an unreleased project. Also I do not vouch for the actual login code at all I just made it up for this example. I'll try to add some more robust examples in the next month. Anyways check it out and tell me what you think: Usage: http://bitbucket.org/ianjosephwilson/pylonsformer/src/tip/pylonsformer/controllers/login.py http://bitbucket.org/ianjosephwilson/pylonsformer/src/tip/pylonsformer/templates/login.mako Major parts of the form handling library that uses formencode and webhelpers(barely): http://bitbucket.org/ianjosephwilson/former/src/tip/former/handler.py http://bitbucket.org/ianjosephwilson/former/src/tip/former/pylonshandler.py On Wed, Oct 28, 2009 at 1:57 PM, Mike Orr <[email protected]> wrote: > > On Wed, Oct 28, 2009 at 2:30 PM, Ian Wilson <[email protected]> wrote: >> >>> > 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? >> >> Yeah I've included such a class. You can seperate GET and POST >> between the prompt and process methods for one thing and you don't >> have to check if the form should be received or sent. Also it will >> compress down to the less general case where both actions are the same >> action. > > Base controllers like your #2 and #3 links are a good idea. Put them > in the Pylons Cookbook and if any of them get highly used, they might > be considered for the Python core. > >>> > 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? >> >> As far as I know formencode will not work unless you pass an object as >> the state, ie. it will not take a dictionary. Therefore everytime you >> need state you make a class, any class. Its just two lines to have it >> do nothing but its two lines I have to write _every_ time I want a >> state object. If you want it to repr/str to something useful you have >> to add that everytime as well. This is the kind of boiler plate that >> by itself is nothing but summing up becomes annoying. Is there a >> Dummy class in the python stdlib? > > ``webhelpers.containers.DumbObject`` > > It creates attributes for its keyword args. It doesn't do anything else. > > There's also ``formencode.declarative.Declarative``, which uses > metaclass tricks to set up standard attributes from positional args. > > The closest thing in the stdlib is ``object``, but you can't use it > for data because its instances won't take attributes. > > -- > 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 > -~----------~----~----~----~------~----~------~--~--- > > -- 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=.
