Kevin Dangoor wrote:
> On 11/28/05, Michele Cella <[EMAIL PROTECTED]> wrote:
> > Kevin, regarding this what do you think about my proposal of hiding the
> > widget insert mechanism behind a custom tag?
> >
> > <widget name="datepicker" [attributes for others options] />
>
> It looks nice, but widgets are designed to take raw Python objects and
> using this form will get you nothing but strings. Some widgets (think
> of multiple selection types of things) will require
> lists/sets/dictionaries... others may require ints.
Yep, you are right.
But IMHO these things should be passed to the widget constructor on the
controller side and not exposed on the template.
Instead of doing this:
def test(...):
options = [make a dict from my model]
optionsel = OptionSelector(...)
return (optionsel = optionsel, options = options)
<div py:replace="optionsel.insert(options)" />
I would like to do this:
def test(...):
options = [make a dict from my model]
optionsel = OptionSelector(options)
return (optionsel = optionsel)
<widget name="optionsel" />
(and only 1 variable on my return method)
Since the .insert() method it's just a presentation method ("put this
widget inside my template") it should just take presentation related
arguments, that's why I also proposed to move the template argument on
the view side (hence removing it from the constructor) in this way:
<widget name="optionsel" template="my_designer_option_selector.kid" />
A designer that is customizing our templates will be able to prepare a
new template for the widget (maybe using the toolbox), put it
somewhere, setup the new attribute (a valid package reference to the
new template) and see the new template applied without the need to ask
the developer to do it (inside the controller).
What I'm trying to say it's that with widget we can still make a clean
controller/template distinction, that's why I think logic bound things
should stay on the controller (at widget instantiation time) and
presentation things should go inside the template at insert time (and
you will only need to use nothing but strings) since they don't need to
be declared on the controller when the widget is created but only when
displayed.
Making powerful widgets (developer side) still easy to customize
(designer side) is the challenge that can give TG a big selling point
over other frameworks IMHO.
Anyway I'm sure I'm most probably missing some use cases where you will
need to pass python object to the insert method on the template, and
this is all crack. :-)
Ciao
Michele
