Mike, I think a lot of folks have ended up writing their own @validate decorator to suit their needs (I have as well). I think there is a new one scheduled for 1.0.
I've moved away from htmlfill in favor of a technique Mike Bayer blogged about here: http://techspot.zzzeek.org/?p=28 I use Bayer's formtags.mako in place of htmlfill, but my @validate is quite different. I really like this formtag.mako approach though. Also, for the repeating elements problem I use another approach from Bayer here: http://techspot.zzzeek.org/?p=29 Note, this blog post isn't specific to repeating fields, but I adapted the idea to my needs. Although the solution requires an ajax call to add a repeating field/fieldset, it is worth it because of the simplicity it offered me. I now have a simple mako template that generates the page on initial GET and repeating fields are added with an ajax call to a mako def within that same template. I've been able to avoid clunky javascript templates or a javascript-clone-rename scheme and I like that. On Jan 7, 8:53 am, "Mike Burrows (asplake)" <[email protected]> wrote: > Make that > if v and not k.endswith('--repetitions')) > to remove empty values that for some reason get placed by htmlfill at > the top of the page and do weird things to page layout! > > In case it wasn't obvious, the helper assumes a "from formencode > import variabledecode" > > Mike > > On Jan 7, 2:50 pm, "Mike Burrows (asplake)" <[email protected]> > wrote: > > > Perhaps you're right - maybe @validate is more trouble than it is > > worth. I have discovered that it doesn't handle repeating elements > > properly: it negelects to flatten the errors dict. I worked around > > this issue in a fill_render() helper which I use to render my forms: > > > def fill_render(template_name, values): > > if isinstance(c.form_errors, dict): > > # UGH! Modify c.form_errors in place, relying on the fact that > > it is > > # aliased to the errors variable in > > pylons.decorators.validate. > > # The validate decorator neglects to flatten any repeating > > groups. > > errors = dict((k, v) > > for k, v in variabledecode.variable_encode > > (c.form_errors).items() > > if not k.endswith('--repetitions')) > > c.form_errors.clear() > > c.form_errors.update(errors) > > return htmlfill.render(render(template_name), > > variabledecode.variable_encode(values)) > > > I appreciate that Pylons isn't 1.0 yet but it concerns me a bit that > > this stuff doesn't work out of the box; makes one wonder that it's not > > used much. As per the start of this thread, it would be cool if > > regular application code didn't need to call > > formencode.variabledecode.variable_encode() (twice!) - all it would > > take is a better render() and a fix to @validate. But is @validate > > definitely the way forward, as opposed to (say) something that might > > be called from within a controller action? > > > I hate to whine - otherwise I'm happy :-) > > > Mike > > [email protected]http://positiveincline.comhttp://twitter.com/asplake > > > On Dec 24 2009, 7:20 am, Ian Wilson <[email protected]> wrote: > > > > On Wed, Dec 23, 2009 at 8:26 PM, Mike Orr <[email protected]> wrote: > > > > On Wed, Dec 23, 2009 at 3:58 AM, Mike Burrows (asplake) > > > > <[email protected]> wrote: > > > >> I'm far too new to Pylons to feel confident enough to contribute > > > >> documentation but I have linked to a few of my blog posts here. I > > > >> don't see too many others doing the same though, so I have to wonder > > > >> about etiquette. Is this to be encouraged? > > > > > It's fine etiquette-wise, as long as it's a few important posts and > > > > not every single one. But from the perspective of somebody looking > > > > for reference material in the future, they'd find it easier if it's > > > > linked in a topic page in the Pylons Cookbook: The developers > > > > periodically go through the Cookbook and put the best pieces into the > > > > official docs, although there hasn't been a sweep recently. > > > > >http://wiki.pylonshq.com/display/pylonscookbook/Home > > > > > For especially short pieces, the Pylons FAQ is a good place. > > > >http://wiki.pylonshq.com/display/pylonsfaq/Home > > > > > There is also the Snippets section on the website, but I've never used > > > > it and I'm not exactly sure what it's for compared to the other two. > > > >http://pylonshq.com/snippets > > > > >> And who is blogging > > > >> regularly about Pylons? The most recent post on Planet Pylons dates > > > >> back to March and I don't know where else to look. > > > > > Ian Bicking (blog.ianbicking.org) and Ben Bangert (groovie.org) have > > > > blogs where they post about Pylons-related software. The Pylons > > > > community as a whole doesn't blog as much as others do, I think > > > > because we're too busy working. The developers are focusing on > > > > finishing Pylons 1.0, and the marketing push has been waiting for > > > > that. > > > > >> On a related topic, how about an occasional post here (perhaps I'm too > > > >> new here to have seen one) and a prominent link on the pylonshq front > > > >> page about how to contribute? Better to confront problems than > > > >> perpetually working around them, don't you think? > > > > > I suppose. I'm not sure what it would say though beyond the usual > > > > open-source stuff: testers and documenters always welcome. It's kind > > > > of been, if you want to contribute, be active on the list answering > > > > questions until you find a task to do, or ask the list or one of the > > > > developers what needs to be done. > > > > > The website has a Contributing menu link but it's broken, hmm. The > > > > there's also a Community section on the wiki although it's not the > > > > easiest to find. > > > >http://wiki.pylonshq.com/display/pylonscommunity/Home > > > > > -- > > > > 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 > > > > athttp://groups.google.com/group/pylons-discuss?hl=en. > > > > Hey everybody, > > > I made a library to wrap up formencode and htmlfill usage in the > > > context of web form submissions that satisfies my use cases: > > > >http://bitbucket.org/ianjosephwilson/formprocess/ > > > > Here is a demo of it with tons of javascript to handle dynamic > > > repeating elements, in the party controller(its a pretty DRY party), > > > you can ignore that if you just want to consider static forms which I > > > demonstrate with the login controller: > > > >http://bitbucket.org/ianjosephwilson/demoformprocess/ > > > > I think some of the repeater stuff might need to go back in the > > > library and the library might still need some more functionality but > > > check it out. It uses formencode and htmlfill. > > > > If someone has a better solution to dynamic repeating fields I would > > > _LOVE_ to hear about it because my solution tastes like spaghetti in > > > vomit sauce. Someone has to be doing it out there somewhere. My > > > solution has always been to relabel inputs and labels so that their > > > order is strictly maintained. This allows elements to be removed or > > > dragged and dropped and still the submission has the correct order. > > > It seems that in the puff(php) you would just do name="name[]" and > > > then the server would get the order of the fields in the POST, is that > > > not reliable? Do we _really_ need name-0, name-1, name-2? Was that > > > just created for something like GET submissions where its an unordered > > > dictionary? I know that formencode wasn't meant to be tied to the web > > > environment directly but maybe something could be done specifically > > > for ordered dictionaries? > > > > -Ian
-- 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.
