While we're removing cruft, how often do people NOT need the first two
members below? As previously mentioned I'd like to get that last one
for free too.
class BaseSchema(formencode.Schema):
"""
Base form schema
"""
allow_extra_fields = True
filter_extra_fields = True
pre_validators = [variabledecode.NestedVariables()]
[also: routes.Mapper(..., explicit=True); mapper.minimization=False -
where the framework defaults are kinda deprecated!]
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.
