Ben Bangert wrote:
> On Oct 30, 2007, at 6:38 AM, Alberto Valverde wrote:
>
>>> I do believe that this is because FE's UnicodeString.from_python returns
>> a str instead of unicode. I'm not too sure of the rationale behind this
>> but, given that most template languages now expect unicode to be used
>> internally (only encoding when finally rendered), I think FE's
>> from_python should also return unicode. This came up some time ago in
>> FE's list, if you google for "toscawidgets" and "unicodestring" in it's
>> archives I'm sure the thread will pop up.
>
> Might be my fault, I think I put the first version of the Unicode
> validator in FE, based on the TG one.
>
>> If he objects to python functions in templates like webhelpers' then I
>> don't think he'd like twForms at all either since fields are rendered
>> this way: ${display_child('name')}.
>>
>> In this scenario twForms might not be a good solution. twForms is a
>> higher-level layer on top of plain html. As with all abstractions, some
>> flexibility is lost in exchange for simplicity.
>
> I thought widgets could have their templates overridden? Wasn't that one
> of the main uses for the Widget browser? Ie, to browse available
> widgets, their options, and see the templates they come with so you can
> customize them if needed.
Yes, they can be customized but in the case of compound widgets (ie:
widgets which display other widgets, like forms) how the rendered
children look like is not immediately obvious by seeing the template.
For example a template could look like this:
<form action="$action" ...>
<p>${display_child('name')}<br /> {error_for('name'}}</p>
<p>${display_child('age')}<br />....</p>
<p>${display_child('address')}</p>
</form>
In this example address is a fieldset with its address fields but you
cannot see it there.
Another problem is that the way html attributes for a field are modified
is not obvious to a designer well versed in html either:
${display_child('name', size=23, maxlength=100)
Keep in mind that tg widgets (twForms' grandma) were originally created
to be used by fastdata which tries to be, or will try to be (really hope
that someday it becomes!) an alternative to django's admin interface.
So, twForms is more geared towards programatically generating forms
(introspecting models, etc...) to quickly generate an interface for lots
of classes than to creating "to-the-pixel" forms where design is crucal
(ie: a signup form). Mike has articulated this point much better than I
did previously in this thread.
Not only programatically... for dull forms, I find more pleasant to edit
and maintain a form definition twForms' style than by editing html.
Alberto
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
