Small form.py enhancement suggestion
Adam Atlas
won't fully accommodate most real-world form applications. It's useful
for quickly testing without worrying about writing HTML, but it
doesn't allow much flexibility in terms of design.
I propose that the Input subclasses' render() methods be changed to
__str__ (or maybe __repr__?). This will facilitate easier inclusion in
templates when you want to use a custom form layout. Given a form.Form
object, a template.py template will simply be able to do
$myForm['blah'] to get the automatic tag generation, without having to
use the table generation. Of course it's not a lot of work to say
$myForm['blah'].render(), but this is just a little bit more
convenient and intuitive. Thoughts?
(Perhaps also we could switch form.Form from __getitem__ to
__getattr__, or allow both. I find that myForm.someField looks better
than myForm['someField'].)
gregp...@gmail.com
> It seems form.py's automatic table generation is rather simplistic and
> won't fully accommodate most real-world form applications. It's useful
> for quickly testing without worrying about writing HTML, but it
> doesn't allow much flexibility in terms of design.
I ended up just adding this method to the form class. But you could
subclass it and do the same thing. Perhaps it should be included in
web.py?
def render_simple(self):
"""Like render but make a field set and divs so you can add
your own styling later."""
#TODO: merge with render??
out = ''
out += self.rendernote(self.note)
out += '<fieldset>\n'
for i in self.inputs:
if isinstance(i,Hidden):
pass
else:
if i.description:
out += ' <div class="input_row"><label for="%s">
%s</label>' % (i.name, i.description)
else:
out += ' <div class="input_row">' #doesn't want
label, but keep table consistent
out += i.pre+i.render()+i.post
out += '<div id="note_%s">%s</div></div>\n' % (i.name,
self.rendernote(i.note))
out += "</fieldset>"
#do hidden inputs, they're hidden so just throw them anywhere!
for i in self.inputs:
if isinstance(i,Hidden):
out+='\n'+i.render() #do I need i.pre, i.post??
return out
gregp...@gmail.com
> __str__ (or maybe __repr__?). This will facilitate easier inclusion in
> templates when you want to use a custom form layout. Given a form.Form
> object, a template.py template will simply be able to do
> $myForm['blah'] to get the automatic tag generation, without having to
> use the table generation. Of course it's not a lot of work to say
> $myForm['blah'].render(), but this is just a little bit more
> convenient and intuitive. Thoughts?
>
> (Perhaps also we could switch form.Form from __getitem__ to
> __getattr__, or allow both. I find that myForm.someField looks better
> than myForm['someField'].)
I second Adam's ideas though. My code fixes the immediate problem,
but these are some good ideas for adding more flexibility.
-Greg
Anand
On 15-Feb-07, at 9:33 PM, gregp...@gmail.com wrote:
>
> On Feb 14, 10:08 pm, "Adam Atlas" <a...@atlas.st> wrote:
>> It seems form.py's automatic table generation is rather simplistic
>> and
>> won't fully accommodate most real-world form applications. It's
>> useful
>> for quickly testing without worrying about writing HTML, but it
>> doesn't allow much flexibility in terms of design.
I agree with you.
Even i was about to suggest the something very similar.
Form constructor can take `use_table` argument to specify whether or
not to use table for rendering.
when use_table=False, it will render using divs, which can be
customized using stylesheets.
Aaron Swartz
> not to use table for rendering.
> when use_table=False, it will render using divs, which can be
> customized using stylesheets.
I tried to design the tables in such a way that they could easily be
customized using stylesheets. I haven't looked at that code in a
while, but Adam's ideas for making customization even easier seem to
make sense.
Anand
On 15-Feb-07, at 8:38 AM, Adam Atlas wrote:
> I propose that the Input subclasses' render() methods be changed to
> __str__ (or maybe __repr__?).
I Agree.
> (Perhaps also we could switch form.Form from __getitem__ to
> __getattr__, or allow both. I find that myForm.someField looks better
> than myForm['someField'].)
may be not. because, it might conflict with the existing members of
Form class.
how about making input available from form.
something like
form.source.foo instead of foo['foo']
or
i = form.source
i.foo
i.blah
Aaron Swartz
How about form.m.foo (m for member?) for symetry with form.d.foo?
Anand
On 15-Feb-07, at 10:22 PM, Aaron Swartz wrote:
>
>> form.source.foo instead of foo['foo']
>
> How about form.m.foo (m for member?) for symetry with form.d.foo?
nice!
I didnt know about form.d.foo is already available.
Adam Atlas
> > form.source.foo instead of foo['foo']
>
> How about form.m.foo (m for member?) for symetry with form.d.foo?
Sounds good to me.