Dan Jacob wrote:
>
> 1. An error_handler argument to @turbogears.expose. This would simplify
> code like this:
>
> ...
>
> @turbogears.expose(html="templates.form")
> def add(self):
> return dict(form=article_form())
>
> @turbogears.expose(inputform=article_form(), error_handler=add)
> # go straight to adding an article and redirect, no need to check
> for errors
>
I like this.
> 3. An "attributes" argument for widgets, for example:
>
> TextField("name", default="Ok", attrs={'size':50, 'maxlength'100'})
> -> also for compound widgets if needed:
>
> f = TableForm(attrs={'enctype':'multipart/form-data'},
> widget_attrs={'name', {'size':50}})
>
Ok, this will work for setting attributes of widgets contained inside
another widget, the dict will probably become quite complex and it
should be passed at insert time (in the template) IMHO.
There is still one problem, how can we manage attributes for widget
with templates that contains "more than one tag"? for example the
TableForm:
<form xmlns:py="http://purl.org/kid/ns#"; name="${widget.name}"
....
<table border="0">
<tr py:for="widget in widgets" py:if="not widget.hidden">
<td>
What if i want to change not only the enctype but also the table border
attribute? and maybe add a class definition to some td?
In this case, probably the only reasonable solution is to customize the
template.
Now, in an ideal world (at least in mine) I would like to let the
designer customize the widget template and be able to still take
advantage of Kid templates that are valid xml files, this is a big
selling point that IMHO we should take into account even for widgets.
So the first step is a tg-admin command that I can use to move inside a
folder and obtain a kid template of the widget I would like to
customize:
tg-admin customize SelectField
Actually this will output something like this:
<div xmlns:py="http://purl.org/kid/ns#";>
<select name="${widget.name}" py:attrs="widget.attrs">
<option py:for="option in widget.options"
value="${option['value']}" py:attrs="{'selected':option['selected']
}">${option['text']}</option>
</select>
</div>
but I want my designer to open it on its browser (or NVU or
DreamWeaver) and editing it, and if you try to paste the above code on
a file and open it you end up with something not quite useful.
The next step is to change how the sample methods works, instead of
preparing a list of widgets and compile the kid template I would like
to provide a kid template that already provides the example, the sample
method will simply output this template without compiling it with Kid
(I must confess that it was not immediate understanding how the actual
sample mechanism works).
This time, tg-admin customize command will provide me with a template
like this, for example for a SelectField:
<div xmlns:py="http://purl.org/kid/ns#";>
<select name="sample" py:attrs="dict(name=widget.name}">
<option py:for="option in widget.options"
py:content="option['text']"
value="10" selected=""
py:attrs="dict(value=option['value'],
selected=option['selected'])">Option Text</option>
</select>
</div>
If you try to open it on your browser it will already work as a sample,
my designer will simply add some attributes here and there and I will
be able to reuse it without further adaptions.
Maybe it's only a crazy idea, but at least for me using a command like
this seems quite flexible, intuitive and faster than cooking up a
dictionary, at least for very complex widgets.
>
> 9. A PSP and world peace :-)
Me too! ;-)
Ciao
Michele
