On Tue, 2003-05-20 at 16:27, Aaron Held wrote:
> Passing in a dict of list of form object that have a known __str__ or
> __repr__ would be great.
>
> From cheetah we should be able to:
> #for $item in FormItems:
> $item
> #end for
Well, it'd be more complicated than that. I guess I could imagine a
simple case like:
<table>
#for $item in form.fields:
<tr><td>$item.description:</td>
<td># if $item.error:
$item.error <br>
#end if
$item.html
</td></tr>
</table>
And that's leaving out compound or repeating fields -- is form.fields
going to be a flat list, or a compound list? And at each level there
can be an error, like compound password/verification fields, they could
individually have errors (like empty password, or weak password), or the
combination has an error, i.e., they don't match. So it's not so clear
how well you can flatten that list.
What's really challenging is the recursive nature of the underlying data
structures. I don't think you want recursive programming in a template
-- it may be a valid way to describe the layout, but if you *ever* want
non-programmers to handle the template, recursion won't work :) Of
course, I am doubtful that a non-programmer will be able to usefully
design forms without a programmer on hand anyway, at least on this sort
of level.
Though maybe there's something with nested forms that would be easier to
understand.
> #for $item in FormItems:
> <$item.tag name=$item.name value=$item.value $extra>
> #end for
Right now the widget is largely opaque. I wouldn't ever expect it to be
this transparent, i.e., that you could construct the tag by hand --
there might be something like:
$item.html(onClick="something", class_="widget")
But some form of separation would be nice, particularly with widgets
like radio fields, where you might want to put them in a specially
formatted table or something. I'm not sure how that would look either.
> Then the template coders could write functions to render form object any
> way they like
>
> Although for <textarea> and <select> it would be more difficult.
As would a SecureHidden field, MD5Password, Ordering, Radio,
Checkbox/MultiCheckbox, File, TextAreaFile, ImageFileUpload, FileUpload,
and ColorPicker -- to name complex widgets already present in FunFormKit
(and which I'll port to FormEncode once it's more stable). I'd like
more, not less, complex widgets -- especially DHTML widgets, like rich
text input, that are a pain to write and work with but would be nice to
encapsulate.
So in most cases the widgets will have to be quite opaque. Things like
Radio would be the exception, if they were made to be taken apart.
Ian
|