Hello Mike,
Thanks for answer, Mike!
> The main Pylons solutions for form generation are:
> 1) A template with a manually-built form.
But if you're building user interface to another program (which is what
I'm trying to do -- and will do lots and lots and lots of it), you need
to recall form settings from some storage. And then this requires
tedious coding in the controller for every option. That is my main
problem. Basic 'proof of concept' which I'm doing now looks like this,
for a form that remembers values that user set before:
Template:
<%def name="form_txt(initstr='', action='')">
<form action="${action}" method="POST">
<select name="choose">
<option ${c.choose_selected['o1']}>o1</option>
<option ${c.choose_selected['o2']}>o2</option>
<option ${c.choose_selected['o3']}>o3</option>
</select>
<input name="user3" value="${initstr}" />
<input name="submit_button" type="submit" value="Save it" />
</form>
</%def>
${form_txt(initstr=c.initstr, action="uf")}
Controller action:
def uf(self):
try:
c.initstr = request.params['user3']
except KeyError:
c.initstr = 'default text'
try:
c.choose_selected = {'o1':'', 'o2':'', 'o3':''}
c.choose_selected[request.params['choose']]='SELECTED'
except KeyError:
pass
return render('uf.mako')
What I mean is that in simple (naive?) approach like this I have to code
for every option in the form using try .. except blocks. Not only this
is tedious, it's error-prone as well.
Which is why I am looking for some solution that in ideal form would be
form generation library or solution allowing to use the same data in the
settings (defaults for options in the forms) e.g. read from some
database and to generate the form in question. Formish example:
schema = schemaish.Structure()
schema.add('mySelect', schemaish.String())
options = [(1,'a'),(2,'b'),(3,'c')]
form = formish.Form(schema, 'form')
form['mySelect'].widget = formish.SelectChoice(options)
Then I could read the settings from db and add them as defaults, you get
the idea.
> 2) Same but with WebHelpers.
> 3) ToscaWidgets.
> 4) FormAlchemy.
>> 2. In simple / naive usage mode it requires mixing HTML and code, which
>> I abhor, on top of it being contrary to the principles of 'separation of
>> layers' in MVC.
>
> I'm not sure what "it" means, unless you're objecting to building
> forms in templates.
I wasn't clear on this, I meant formencode.htmlfill form manipulation
which in simple example from the docs requires mixing html and
controller code:
>>> from formencode import htmlfill
>>> form = '<input type="text" name="fname">'
>>> defaults = {'fname': 'Joe'}
>>> htmlfill.render(form, defaults)
'<input type="text" name="fname" value="Joe">'
That is, unless you get values of 'form' and 'defaults'-like variables
from another place and not code them directly in the controller, obviously.
> But a form is intrinsically a user interface
> object. In some cases the exact look is unimportant enough that a
> programmatically-generated form (ToscaWidgets) is acceptable. In
> other cases the form needs so many customizations that it's not worth
> creating a ToscaWidgets widget set for it. My client is prone to say
> "put this text here next to this one field, and move these three
> fields in a row, no, wait, change it back". This is easier to manage
> with a template+WebHelpers form.
Fortunately I don't have that problem.
<snip good stuff>
Thanks for explanation!
Regards,
mk
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
