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.com
http://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.
