I always try to stay away from "Dynamically add fields to the form" whenever
I can, and instead rely on using multiple forms on multiple pages to achieve
the same effect. I realize that this is not always an option but it's
something to consider. Especially on local networks where the pages load so
fast that two pages load with a slight change between them is almost
indistinguishable from using javascript.
As for fields not showing up on static templates, for more advanced forms
I've tried to structure my templates so that the context being rendered
could be the list of dates I retrieved somehow from the database, OR the
list of dates I retrieved from the form results, but not both. So, the
template...
% for i, date in enumerate(c.form['dates']):
${my_helper.render_date_field(i, date)}
% endfor
...has this "form" object in the context. This could be as simple as a
dictionary. On the initial rendering, I'm taking the known data, converting
it into a dictionary, and using the dictionary for the "form" variable. When
rerendering with errors, I just use the form results for the "form"
variable.
You can take this idea and run with it. I typically use a wrapper so I can
use the attribute syntax (form.dates) rather than the lookup syntax
(form['dates']). The wrapper I use also has the ability to automatically
determine ids, so stuff like...
% for game in c.forms.games:
% for player in game.players:
<label for="${player['id']}" >Player:</label>
<input type="text" name="${player['name']}" id="${player['id']}"
value=${player}/>
The id for the second player in the first game would be "game-0.player-1"
Of course, this whole idea comes with drawbacks:
First off, you need additional code to convert from the original model to
the dictionary, and although it's often pretty trivial, it's still code.
Likewise with the form results dictionary back to model when saving, but
that typically needs to be done anyway.
Second is that the pylons validate decorator probably shouldn't be used, but
I don't see that as a big loss (it's slated for a rewrite anyway). I've just
used my own functions for that part to simplify the validation handling.
Finally, you need to make sure that on the javascript side you are
generating the correct ids for your fields, but I think you'd have this
problem anyway if you're not using a framework. Anyone know of a javascript
library to help with that sort of thing? At some point I'm gonna' take a
look at some of these libraries that have a feature like this and see what
they do for javascript and just make a stand-alone script for helping with
these kind of things.
Anyway, I've only just been playing with doing it this way for a week or two
on a side project, so I'm still flushing out the details. But maybe it'll
spark some ideas for you.
Regarding tw, I've been meaning to try it out again (I tried it once a few
years ago, but might have better success having gained a bit more
experience). I'm just kinda creaped out that tw doesn't even seem finished
and they're already working on tw2, which perhaps I'm just reading too much
into.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
