[Perl-widget-developer] Dynamically configured Widgets (Was: [Perl-widget-developer] thoughts on design)

[Cees H. <ce...@si...>]

On Sun, 3 Jun 2001, Stephen Adkins wrote:
> 1. I am encouraged that someone is looking at the code.
>    Good for you Cees.
> 2. Your suggestions are good, but your patches conflict with things
>    that I am working on.  I understand that it was worth it to you
>    just to play with the code.

I figured as much, but that's no problem.  After looking at version 0.02,
I think you have covered most of what I talked about.

> >In the first release, the Widgets were conpletely driven by hte Config
> >object.  I have added some support that allows the widgets to be
> >configured at initialization time as well as from the Config object.  
> >This allows someone to create a Widget as such:
> >
> >    $widget = $wc->widget(
> >        -name       => 'category',
> >        -class      => 'Widget::HTML::Select',
> >        -values     => ['Foo', 'Bar'],
> >    );
> 
> I knew people would want to do this, and I have been working on adding
> it myself.  However, I consider this usage the "low road".  It encourages
> people to do exactly what the library is supposed to get them away from ...
> caring about the details of the widget.  It also inhibits the configurer
> from snapping a new implementation of a widget in to upgrade the page.

I guess what I am looking for is some hooks that allow developers to
generate widgets without requiring a configuration file.  There are 2
situation where I think this is necesary.

First situation:  If we build a complex widget by combining several simple
widgets (a good example is the DateDropDowns widget), then the simple
widgets should not be required to be configured by the config file.  
Using the DateDropDowns as an example, there are never going to be more
than 31 days in a month, so why waste config file space to hold them?  
The config file should contain options and values that the user may want
to change, if it doesn't make sense to change it, then it shouldn't be in
the config file.

So the DateDropDowns.pm code should be able to do somethin like this:
$date.day = $wc->widget(-name   => 'date.day',
			-class  => 'Widget::HTML::Select', 
			-values => ['01'..'31']);

The same can be done for months and years, although we could add a config
option that asks if they want to use full months (ie 'January',
'February') or short months (ie 'Jan', 'Feb'), and perhaps the range of
years to include in the widget.

This way the user doesn't need to know anything about the 'sub-widgets'
that DateDropDowns uses internally.  It will make the configuration files
much cleaner and user friendly...


The second situation is where you need a dynamic widget.  For example a
select box where the options depend on a database query.

$sth = $dbh->prepare(q{
        SELECT category_id, category_name
	  FROM categories
	 ORDER BY category_name
});
$sth->execute();
$data = $sth->fetchall_arrayref();
$categories = $wc->widget(-name => 'categories', -values => $data);

Where -values will contain a 2 dimensional array of values and labels (or
some similar mechanism)


Comments ??


Cees Hek