Hi,
Development of a straw-man set of Perl Widget Library core classes is
going well. A Sourceforge project (perl-widget) is in the process of being
set up too. (I will announce when it is set up.)
The first 0.01 release will be for public comment on
the structure and concepts of the core classes.
With regard to all of the debate on closures/classes/etc., let me say that
I intend for the PWL to be useful in a variety of environments with
different people using more or less of the features.
I am favoring flexibility over performance at the moment, so full classes
are being used to access the different features of the different systems
with which it will need to interface.
At the low end, the PWL will support the simple use that Gunther requires:
simple generation of HTML of a named widget based on configuration
information.
At the high end, Jay Lawrence and I envision much more sophisticated
features ...
but let's not let the consideration of those get in the way of
accomplishing our
first task as described above.
A Template Toolkit user should be able to say
[%PERL%]
use Widget;
$stash->{wc} = Widget->controller();
[%END%]
Birth Date: [% wc.widget("birth_date") %]
or eventually something simpler like
[% USE wc = Widget %]
Birth Date: [% wc.birth_date %]
and the appropriately configured HTML will be inserted.
For non-users of Template Toolkit, they can do the comparable perl ...
use Widget;
$wc = Widget->controller();
$widget = $wc->widget("birth_dt");
print "Birth Date: ", $widget->html(), "\n";
The rendering of this widget as HTML requires at least the following
* config information (Widget::Config)
* state information (to get the current value) (Widget::CGI::State in a
CGI environment)
The state information can be accessed from *any* source by implementing an
appropriate
Widget::<DataSource>::State class (and using some additional,
not-yet-implemented arguments
to Widget->controller()).
see below for more comments ...
At 11:10 PM 5/28/2001 +0800, Gunther Birznieks wrote:
>At 02:16 AM 5/25/01 -0400, Stephen Adkins wrote:
>...
>>I have done the Widget.pm convenience functions and factory code.
>>I am working on the Widget::Config class to read XML config data using
>>XML::Simple.
>>Then on to Widget::Base a parent class for all implemented widgets.
>>Then on to Widget::Controller which will be handed a CGI object
>>(or Apache::Request or whatever using one of the much-commented on schemes)
>>and dispatches events detected from submit buttons, etc.
>>Then I do my first actual widget, Widget::HTML::Date.
>>I'll camp on this while I get lots of feedback.
>
>I don't understand the Widget::Controller. Can you say more about this?
The Widget::Controller (or perhaps, Widget::CGI::Controller) is the
container class
that you spoke about in your original post. I call it a Controller rather
than
a Container because I envision it being able to dispatch events generated
by the
widgets.
>Also will we require XML to configure? Or is this also an optional feature
>that you more or less want for yourself but others can choose to not use?
Configuration data is read in via the Widget::Config class, and this class can
be replaced with a class which reads config data from any other source, as
long as
it conforms to the same calling interface.
I was under the impression that XML was your desired means of writing a
config file.
Do you have a preference to use something different?
>Thanks,
> Gunther
Stephen
