I'm not completely done with the widgets work, but I think the main
API is looking a lot better. I wanted to open up for comments,
suggestions and patches.

First of all, you can "activate" the new widgets code like this:
from turbogears import widgets
widgets.use_new_widgets()

So, what's different?

* create_dict is gone! it has been replaced by adjust_value and
update_data. Subclassing is much cleaner now, I think

* all of those crazy parameters to create_dict, insert and render have
been eliminated. Just pass in appropriate keywords for your widgets.
(the value parameter for the first parameter is still supported, of
course...)

* widget.insert has been renamed widget.display

* widget.input has been renamed widget.validate

* display() now returns an Element (you'll want to update TurboKid,
but it'll probably still work even if you don't). render() works off
of display, so if you're trying to generate HTML in some non-Kid form,
you really only need to implement display.

* No more label widget associated with a field. form
  fields now just have label text. Use of "labeltext"
  previously should now be "label"

* form.widgets is now form.widgets["fields"]

* disabled_fields on forms has become disabled_widgets

* as mentioned earlier, widgets can no longer be modified after
they've been displayed, to help ensure threadsafe use of the widget

The widget sample and source functionality is going to be broken out
into a new class. It will become more powerful and useful in the
process (ultimately leading to a better Toolbox Widget Browser).

Limitations:

* the select widgets are untested, as far as I know. they're probably
broken and, at the very least, they don't support callables as they
should

* CalendarDatePicker and AutoCompleteField are just plain missing

* the widget browser in the toolbox is *completely* broken

I'm going to work on those 3 things that I list as limitations above.
Anything else is fair game for patches.

I hope people find this rearrangement pleasant... it shouldn't take
long to convert widgets from the old style to the new.

Kevin

--
Kevin Dangoor
Author of the Zesty News RSS newsreader

email: k...@blazingthings.com
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com

A major omission from the message I just sent: this revision of the
widget implementation is based on code by Michele Cella. I've also
blended in input from David Bernard who had some proposals up on the
wiki.

A couple more things of note:

* the widget templates are much simpler (code has productively moved
into Python)

* error display is now the responsibility of the form and not the
widget (though you certainly can make widgets that include the error
display)

* most of the "form" related widgets have moved into the "newforms"
module. This represents a cleaner separation between widgets that just
display things and widgets that actually get input

* widgets that combine other widgets now have a common ancestor
(CompoundWidget) to help out. Karl Guertin had a proposal floated for
one of those, and I'm not sure if all of his ideas made it in.

Kevin

On 2/2/06, Kevin Dangoor <dang...@gmail.com> wrote:

Another thing: the widget itself is no longer automatically provided
to the template namespace. This encourages two things:

1) threadsafe use (since you can't just dump things in the widget and
grab them from the template)

2) moving more computation to the Python code (since you'll likely
need to create an update_data method to give data to the template
anyhow)

Kevin

On 2/2/06, Kevin Dangoor <dang...@gmail.com> wrote:

Hurra. :-)

Regarding this, since we support options at the constructor I think we
should also add options here at display time (and fix the problem with
_collect_options making options a property see #490).

That's just to provide a default suggested way of passing options (of
any type, choices for a selectfield) along from a form to it's fields
as the actual form I made does. What do you think?

I mean:

    def display(self, value=None, options=None, convert=True, **kw):

Just to be coherent:

default -> value
options -> options

I left it to be disabled_fields AFAIK. :-/

I noticed they don't work anymore as on my initial implementation (that
Alberto tested), anyway I will left the selection field to you so you
can check things, the CheckBox is now broken also (still using
create_dict and not respecting the default value), I'm cooking a patch
(with a test to show the supposed behavior).

Great work by the way.

Ciao
Michele

On 2/2/06, Kevin Dangoor <dang...@gmail.com> wrote:

I've been holding off on messing around with compound widgets until
the majority of the widgets updates had landed. I'll definitely be
looking into this and the rest of the widgets changes over the
weekend.

Until widgets have calmed down, my CMS has no editing capability.  ^_^;
I want to use stored sets of widgets to automatically update all of my CMS
objects from one central controller.

application_pgp-signature_part < 1K Download

I've attached the patch to ticket 490, it adds a bunch of tests (for
CheckBox, SelectFields, ...), I've also ported all the widget in
newforms.py to use update_data and fixed some things here and there.

Finally I've integrated Alberto's patch for callable options and added
a test for this.

All SelectionField seems to work just fine, at least from the tests
I've made. :-)

Ciao
Michele

Great! Looks as the widget-waters are calming down, aren't they? I'll
take this words as an invitation to update #502 to the new-new-style
and the rest of my apps widgets... (please stop me before it's too
late... ;)

Nice work both of you! I'll post anything I find
broken/strange/whatever at the Trac.

Regards, Alberto

Man, my notes on these changes were awful.

As noted below, the widget is no longer in the namespace of the
template. What I didn't mention is that I simplified a lot of the
variable names. Since these templates are very special purpose and
just for widgets, things like "widget_value" just became "value". At
this point, using simpler names seemed to make sense, and it didn't
seem to me that name collisions were going to be a giant problem.

Kevin

On 2/2/06, Kevin Dangoor <dang...@gmail.com> wrote:

On 2/2/06, Michele Cella <michele.ce...@gmail.com> wrote:

I think "options" should only exist for select fields. Otherwise, a
widget should use named parameters for the things that are of
interest/value to it.

One thing that may be useful to do is allow you to put a list of
widget attributes that you'd like to make available to the template
and have that do the equivalent of:

d[that_attribute] = d.get(that_attribute, getattr(self, that_attribute))

That would make all of these types of things overrideable at display()
time. We could, if it's desirable, make that automatically call a
callable, but I'm a bit less certain on that one.

I think I may have actually written that note backwards :(

It's disabled_fields.

Thanks for writing those tests! That was a big help! Always nice to
know that more of the functions are tested.

Thanks, and same to you!

Kevin

What name collisions are you refering to? I have not noticed them or
something strange going on.

Tests are all running fine.

Ciao
Michele

On 2/3/06, Michele Cella <michele.ce...@gmail.com> wrote:

I was referring to the name collisions that don't exist :)

If memory serves, I originally passed "widget_value" to the template
instead of "value" because I didn't want to collide with variable
names used by user-created widgets. Those are the name collisiions
that i think are not much of an issue.

Kevin