Mmm, it's sunday guys away all day long and just coming here... :D
Just to entirely quote Alberto... that's why we introduced
display_field_for and render_field_for, almost total freedom of
customizing a template for a designer and a much easier way of managing
forms for the developer (or do you want to keep rewriting validation
code, errors managing, error displaying?), the example proposed by
alberto is still using the widget template but you can also use
dispaly_field_for inside a normal kid template, for example if you're
passing the form to the template:
return (form=...)
in the template:
<form>
form.display_field_for('name', value=...)
<input type="submit" />
</form>
and you've got a totally designer usable template with "zero" change on
the controller side.
On one thing we should do (and will (soon)) to improve widgets is
writing good, clear and easy documentation that's almost 1% ATM. :-(
That's why from 0.9a1 to 0.9a2 we have been running and committed
everything we had in mind for widgets and now things (at least from the
API POV) are basically in feature freeze.
Ciao
Michele
Alberto Valverde wrote:
> On Mar 26, 2006, at 10:40 PM, Steve Bergman wrote:
> >
> > While what the form and fields send back lies within the purview of
> > the
> > programmer, how the fields are laid out on the page is really in the
> > realm of the designer.
> >
>
> Thats why you can let the designer lay out a form in a .kid file,
> using display_field_for("fieldname") to precisely lay each field
> wherever he/she may please and use this template file's path (in the
> same dotted path notation used at expose). The Widget subclass will
> then take care of all the validation, js & css including, etc like
> the *programmer* wants, no chance for the designer to mess it up as
> he only needs to edit the kid file.
>
> The reason I use widgets in my projects (apart from being *way* more
> pleasing than HTML to maintain & test) is that you can easily reuse
> all the widget package in any other project. Simply make an egg out
> of it (widget class, inline or kid file template, validator,
> javascript and css) and write an entry_point for it in setup.py and
> you're done. You can even preview them in the widget browser like the
> core TG widgets.
>
> To put in code:
>
> widgets.py
> ---------------
>
> from mywidgets import TinyMCEWidget # not included in TG core
> from turbogears.widgets import CalendarDateTimePicker, Form
>
> class MyForm(Form):
> template = ".templates/myform"
> fields = [CalendarDateTimePicker("date"), TinyMCEWidget("text")]
>
> myform.kid
> ---------------
>
> <form xmlns:py="http://purl.org/kid/ns#";
> name="${name}"
> action="${action}"
> method="${method}"
> py:attrs="form_attrs"
> >
> ${display_field_for("date")}
> ${display_field_for("text")}
> </form>
>
> Now you simply pass myform.kid to the designer and he/she can open it
> in DW or his favorite WYSIWYG editor and do his/her fancy stuff with it.
>
> Alberto
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" 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/turbogears
-~----------~----~----~----~------~----~------~--~---
