Repeating elements and htmlfill
Mike Burrows (asplake)
htmlfill.render() doesn't seem to handle repeating elements as I
expect. I've boiled my code down to this example:
import formencode.htmlfill as htmlfill
template = '<input id="weightings-0.weight"
name="weightings-0.weight" type="text" value="" />'
print htmlfill.render(template, defaults={'weightings':
[{'weight': 1.0}]})
print htmlfill.render(template, defaults={'weightings-0.weight':
1.0})
Output:
<input id="weightings-0.weight" name="weightings-0.weight"
type="text" value=""/>
<input id="weightings-0.weight" name="weightings-0.weight"
type="text" value="1.0" />
See how the first render fails to populate a value. Am I doing
something wrong? I've using version 1.2.1.
Are there any good examples out there? Chapter 6 of the 1.1 book
covers some of this but it's not complete (it also has a bug unless
I'm missing something - "person" and "people" are used
inconsistently).
Thanks,
Mike
m...@asplake.co.uk
http://positiveincline.com
http://twitter.com/asplake
Ian Wilson
You need to preprocess your defaults with
formencode.variabledecode.variable_encode() to change the first case
into the second case.
I'm still working on a good repetitions example, are you using
javascript? You should look at formencode's NestedVariables,
variable_encode and variable_decode to start.
Mike Burrows (asplake)
On Nov 2, 8:32 pm, Ian Wilson <vengfulsquir...@gmail.com> wrote:
> Yeah as far as I know it does not work like that for the first case.
> You need to preprocess your defaults with
> formencode.variabledecode.variable_encode() to change the first case
> into the second case.
> I'm still working on a good repetitions example, are you using
> javascript? You should look at formencode's NestedVariables,
> variable_encode and variable_decode to start.
book and thought I'd see how I would get on with the approach outlined
there. After struggling a little I decided to play it safe and not
add rows dynamically (by either method) to start with. Either way,
the need to populate the form with data remains.
I have NestedVariables and ForEach in my parent form schema, but (in
my code at least) they don't come into play until validation time.
Anyway, I hope to understand this a bit better after following your
first piece of advice.
A really solid good example of this would brilliant. Forms in Pylons
do take a bit of getting used to (which is about the worst I can say
about what has been a positive experience for the most part)!
Thanks & regards,
Mike
Mike Burrows (asplake)
Makes one wonder why this (and NestedVariables) can't be there by
default though - it would make for a much smaller gap between the
easy, documented examples and the real world! All it would take is an
enanced render method and perhaps a subclass of Schema. Or perhaps
this goes on a list of recommended things to go in base.py (or
similar)?
For the record, my little example now looks like this:
import formencode.htmlfill as htmlfill
from formencode.variabledecode import variable_encode
print htmlfill.render(
'<input id="weightings-0.weight"
name="weightings-0.weight" type="text" value="" />',
variable_encode({'weightings': [{'weight':
"1.0"}]}))
Easy when you know how!
Regards,
Mike
Mike Burrows (asplake)
Chris
recreating the repeated fields on form validation error? For example,
I'm adding repeated fields via javascript, then we the form POST
occurs and validation fails, I need to figure out how to recreate
those fields in the form. The pylons book example, does solve the
problem, but it sure seems like a lot of code to write for every form
that has a nested structure.
Has anybody got an elegant solution for recreating javascript-added
repeat fields when the form is invalid?
The path I'm heading down is to just use ajax to submit the form.
This keeps the form intact. But now, I have to fill in the error
messages via javascript. Something like,
1. Initial GET, use htmlfill to fill in defaults or model obj values
2. User adds extra repeatable fields via javascript, then submits via
jquery.form plugin
3. Form validation fails, controller returns the formencode error dict
as JSON
4. Javascript will fill in the error messages on the fields
This works reasonably well, but I'm just wondering if anybody has a
better solution.
Regards,
Chris
On Nov 5, 6:38 am, "Mike Burrows (asplake)" <m...@asplake.co.uk>
wrote:
Mike Burrows (asplake)
Having got stuck with the basics of populating and validating the
form, I haven't got round to adding rows (dynamically or otherwise).
I think I've got my head sufficiently around the book example to
implement it now but I may yet decide to take the Javascript option.
Meanwhile, I just ensure that there are more enough rows displayed.
Yes the book example is a lot of code (in particular that's a lot of
logic for one action method) but maybe it can be turned into something
reusable. Fantastic if it could...
Regards,
Mike
Mark
problem grasping the concepts of Pylons.
I also ran into the same problem at work...It's so irritating.
On Nov 6, 3:28 pm, "Mike Burrows (asplake)" <m...@asplake.co.uk>
wrote:
> Hi Chris,
>
> Having got stuck with the basics of populating and validating the
> form, I haven't got round to adding rows (dynamically or otherwise).
> I think I've got my head sufficiently around the book example to
> implement it now but I may yet decide to take the Javascript option.
> Meanwhile, I just ensure that there are more enough rows displayed.
>
> Yes the book example is a lot of code (in particular that's a lot of
> logic for one action method) but maybe it can be turned into something
> reusable. Fantastic if it could...
>
> Regards,
> Mike
>
> On Nov 5, 4:07 pm, Chris <fractalbynat...@gmail.com> wrote:
>
> > Thanks for posting this. How have you solved the problem of
> > recreating the repeatedfieldson form validation error? For example,
> > I'm adding repeatedfieldsvia javascript, then we the form POST
> > occurs and validation fails, I need to figure out how to recreate
> > thosefieldsin the form. The pylons book example, does solve the
> > problem, but it sure seems like a lot of code to write for every form
> > that has a nested structure.
>
> > Has anybody got an elegant solution for recreating javascript-added
> > repeatfieldswhen the form is invalid?
>
> > The path I'm heading down is to just use ajax to submit the form.
> > This keeps the form intact. But now, I have to fill in the error
> > messages via javascript. Something like,
>
> > 1. Initial GET, use htmlfill to fill in defaults or model obj values
> > 2. User adds extra repeatablefieldsvia javascript, then submits via
Mike Burrows (asplake)
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? 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. Seeing people work
through issues and find solutions that are elegant both framework-wise
and language-wise is something I have very much appreciated in other
communities.
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?
Regards,
Mike
Wyatt Baldwin
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?
Yes. Do it. :)
Mike Orr
<m...@asplake.co.uk> 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 <slugg...@gmail.com>
Ian Wilson
>
> You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
> To post to this group, send email to pylons-...@googlegroups.com.
> To unsubscribe from this group, send email to pylons-discus...@googlegroups.com.
> For more options, visit this group at http://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
Mike Burrows (asplake)
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 :-)
On Dec 24 2009, 7:20 am, Ian Wilson <vengfulsquir...@gmail.com> wrote:
> > Mike Orr <sluggos...@gmail.com>
>
> > --
>
> > You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
> > To post to this group, send email to pylons-...@googlegroups.com.
> > To unsubscribe from this group, send email to pylons-discus...@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/pylons-discuss?hl=en.
Brian O'Connor
params = dict(request.params)
params['staff_authors'] = request.params.getall('staff_authors')
allow_extra_fields = True
filter_extra_fields = True
# other fields....
staff_authors = formencode.ForEach(ExistingStaffMember())
Brian O'Connor
Mike Burrows (asplake)
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)" <m...@asplake.co.uk>
wrote:
> m...@asplake.co.ukhttp://positiveincline.comhttp://twitter.com/asplake
Mike Burrows (asplake)
Right. And you could easily do additional validation without having
to wrap it up in a FancyValidator or whatever. I may go this way
myself.
> > pylons-discus...@googlegroups.com<pylons-discuss%2Bunsu...@googlegroups.com>
> > pylons-discus...@googlegroups.com<pylons-discuss%2Bunsu...@googlegroups.com>
Mike Burrows (asplake)
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)" <m...@asplake.co.uk>
wrote:
> m...@asplake.co.ukhttp://positiveincline.comhttp://twitter.com/asplake
Chris
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)" <m...@asplake.co.uk>
Mike Burrows (asplake)
Thank you Chris for the pointer - it looks very good on a quick read
and I will study it properly.
Mike Orr
On Thu, Jan 7, 2010 at 10:35 PM, Chris <fractal...@gmail.com> wrote:
> 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.
It's been postponed till after 1.0 because otherwise it would hold up
the release significantly.
http://pylonshq.com/project/pylonshq/ticket/405
"milestone changed from 0.10 to 1.0.1
"Right, so I think changing @validate pre-1.0 will screw up too much.
I think a cleaner idiom alltogether is needed, since validation
requires so many options we're weighed down with a massive @validate
with a dozen keyword options that's just horrid.
"@validate should be deprecated post-1.0 when a cleaner way to utilize
FormEncode? in a controller is completed."
The new approach may or may not involve a decorator. I suspect not,
because an action can't inject 'state' into a decorator.
> 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.
I do something partway. I use def-with-content to layout a field,
but with no preprocessor and just using ModelTags or the tag helpers:
# Function
## *********** FORM FIELD *******************
<%def name="field(name, label, required=False)">
<div class="field-row">
<label for="${name}">${label} \
% if required:
<span class="required">*</span> \
% endif required
</label>
<blockquote class="widget">
<form:error name="${name}" />
${caller.body()}
% if hasattr(caller, "hint"):
<div class="hint">${caller.hint()}</div>
% endif hint
</blockquote>
</div>
</%def>
# Usage
## 'first_name' field
<%call expr="field('first_name', 'First Name', True)">
${mt.text("first_name", size=60, maxlength=60)}
</%call>
# Result
<div class="field-row">
<label for="first_name">First Name <span class="required">*</span> </label>
<blockquote class="widget">
<input id="first_name" maxlength="60" name="first_name" size="60"
type="text" value="Mike" />
</blockquote>
</div>
I have to call htmlfill both for display and validation because of the
<form:error> tag. I either do that manually after rendering, or put
the whole form-generation into a utility method called by both
actions.
I'm not sure if an enhanced render() is feasable for Pylons because
render is supposed to be a simple function that interfaces with a
template system and can be reimplemented for other template systems.
But maybe a wrapper class would work:
from pylons.templating import render_mako
from pylons.somewhere import FormEncodeRenderWrapper
render = FormEncodeRenderWrapper(render_mako)
Then the wrapper could concern itself with forms and validation,
leaving the renderer intact. Anyway, if you have concrete ideas you
can make a Pylons ticket for them, or put an article in the Pylons
Cookbook and give us a link to it. That way maybe users could use it
before Pylons incorporates it.
>> On Jan 7, 2:50 pm, "Mike Burrows (asplake)" <m...@asplake.co.uk>
>> > 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.
It's just a large task and the developers haven't had time to improve
it. It works in most cases, so it hasn't been a critical problem. It
just has limitations and an annoying API.
--
Mike Orr <slugg...@gmail.com>
Mike Orr
<m...@asplake.co.uk> wrote:
>
> 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()]
You'd have to ask on the FormEncode list for this. I agree they'd be
useful defaults.
> [also: routes.Mapper(..., explicit=True); mapper.minimization=False -
> where the framework defaults are kinda deprecated!]
Added a ticket for this.
http://bitbucket.org/bbangert/routes/issue/25/time-to-modernize-the-mapper-defaults
--
Mike Orr <slugg...@gmail.com>
Mike Burrows
Thanks again Mike and everyone - this has been a very informative
thread.
> You'd have to ask on the FormEncode list for this. I agree they'd be
> useful defaults.
Right - I will follow up with them,
> > [also: routes.Mapper(..., explicit=True); mapper.minimization=False -
> > where the framework defaults are kinda deprecated!]
>
> Added a ticket for this.
>
> http://bitbucket.org/bbangert/routes/issue/25/time-to-modernize-the-m...
Thanks. I may submit a patch.
Regards,
Mike Burrows
m...@asplake.co.uk
Chris
http://marcuscavanaugh.com/posts/pylons-django-forms/
Mike Orr
> One more alternative I forgot to mention about form handling:
> http://marcuscavanaugh.com/posts/pylons-django-forms/
A few people have mentioned using django.forms with Pylons and have
been pleased with it. There's another project WTForms which is
similar and doesn't depend on Django.
We considered replacing FormEncode with WTForms in Pylons, but
FormEncode is incredibly flexible because it only tries to do one
thing, and we didn't want to lose its functionality in edge cases. For
instance, I use it to validate my INI dict and convert the values. You
could do that with WTForms but the code is so HTML-centric it feels
funny. The FormEncode situation will improve when I have time to write
a better manual (after I finish the WebHelpers docs), and after we
come up with something better than @validate.
--
Mike Orr <slugg...@gmail.com>
Chris
is very clean and small and it also offers an immediate alternative to
@validate (and htmlfill). It does include html generation through
python class-based widgets (vs mako style widgets), but it still lends
ample flexibility when doing so.
FormEncode is great too, but also seems more complex. I often find
myself wondering if I'm sub-classing the right thing or overriding the
right methods in my custom validators. For example, when subclassing
FormValidator, you override .validate(), when subclassing
FancyValidator you do ._to_python(). But you can also have a
FancyValidator subclass act as a form validator if it is run in
chained_validators. There so many ways to do things, I'm just not
sure if I'm doing any of them right. Of course, my understanding of
FormEncode could be completely wrong!
On Jan 10, 9:42 pm, Mike Orr <sluggos...@gmail.com> wrote:
> Mike Orr <sluggos...@gmail.com>
Mike Orr
> FormEncode is great too, but also seems more complex. I often find
> myself wondering if I'm sub-classing the right thing or overriding the
> right methods in my custom validators. For example, when subclassing
> FormValidator, you override .validate(), when subclassing
> FancyValidator you do ._to_python(). But you can also have a
> FancyValidator subclass act as a form validator if it is run in
> chained_validators. There so many ways to do things, I'm just not
> sure if I'm doing any of them right. Of course, my understanding of
> FormEncode could be completely wrong!
I don't use FormValidator. I thought it was the validator for forms,
but when I interviewed Ian he said it's for cases where you want to
chain to another validator even if the form is partially invalid.
I've never understood when that would be useful.
I use Schema when it's convenient, and FancyValidator otherwise.
--
Mike Orr <slugg...@gmail.com>