At 12:15 PM 5/28/01 -0400, Stephen Adkins wrote:
>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.
I think this makes sense. I would like to see the model worked out well
before eeking out the performance.
>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.
Thanks. :)
>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";
I think this seems reasonable.
>The rendering of this widget as HTML requires at least the following
>
> * config information (Widget::Config)
I'll talk about config in a bit.
> * 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()).
I think it would be better as a Widget::State::<DataSource> rather than the
other way around. From the way you describe it, this is really an interface
to getting state information that should be retrieved from a DataSource
specific state driver.
>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.
Ah. I just want something to contain the widgets essentially. So perhaps
from my perspective events aren't necessary and I would potentially just
place the widgets into an array representing my HTML screen.
> >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?
I like XML for Config files, we use that in our Java stuff all the time.
But Perl is one of the nicest and flexible config file languages out there.
IE My config file is Perl.
Anyway, I think it is weird to think of configuring just widgets. Usually
you configure an application and widgets are a part of that. But everyone
here will have a different way of preferring to write their application
config whether it's XML or Perl and what features of these that are used
(eg just a set of scalars or references to hashes or ... ?) or in the case
of XML using attributes versus subtags...
I am not quite sure that the configuration is so extensive for each
individual widget that it can't be done by having a named parameter
constructor similar to that handled by CGI.pm rearrange() calls.
Maybe what makes sense is that your Widget::Controller that deals with
events is separate and used in your application and is more complex so it
needs config. I don't see it being something that necessarily needs to be
included in what I need Widget's for.
Anyway, no matter what I dislike forcing the use of a toolkit to have to
use XML except as an advanced option. Many of the parsers require binary
compilation and at that, parsing XML is much slower than simply passing a
config data structure written in Perl itself.
This is a problem for people like me who write applications that must run
everywhere very easily. So although I like to optimize if possible for
mod_perl, I also want mod_cgi users at most any ISP able to use our scripts
without having to force the ISP to compile a module.
Thanks,
Gunther
