At 09:49 PM 5/29/2001 +0800, Gunther Birznieks wrote:
>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 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.
I have come to the same conclusion.
I am changing the design to have three core base classes (other than the
widgets):
Widget::Controller
Widget::Config
Widget::State
A CGI program might run with the following derived classes:
(These are the initial defaults I am working on.)
Widget::Controller::CGI
Widget::Config::XML
Widget::State::CGI
All of these "drivers" may be overridden, as long as the driver you replace it
with conforms to the interface definition described by the core base classes.
(Kind of like a Java interface. You would be encouraged to derive from the
core base classes, but that is not necessary.)
...
>> >
>> >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.
>
I have found that event handling comes in surprisingly handy even for
simple tasks.
Essentially, it allows widgets to define callbacks.
For instance, the DateDropDowns widget defines an event "change"
(modelled after the Javascript "onChange" event) that, when triggered,
concatenates
the YYYY, MM, and DD back into YYYY-MM-DD.
The following is working code.
Notice that the "$wc->dispatch_events($query);" statement takes care of
whatever widget housecleaning there may be (in this case, recomposing the date
as a single variable from the three drop-downs).
::::::::::::::
cgisample
::::::::::::::
#!/usr/local/bin/perl -w
##############################################################
# cgisample
##############################################################
# This is an example of a CGI script that uses the capabilities
# of the Perl Widget Library minimally.
# It looks like any other perl script which uses the CGI.pm
# library.
# See 'wexec' for an example of a CGI script that uses
# the full capabilities of the Perl Widget Library.
##############################################################
use lib "/usr/ov/acoc/dev/src/Widget";
use CGI;
$query = new CGI;
use Widget;
$wc = Widget->controller();
$wc->dispatch_events($query);
print <<EOF;
Content-type: text/html
<head>
<title>cgisample</title>
</head>
<body bgcolor=#ffffff>
<h1>cgisample</h1>
<hr>
<form method='POST'>
EOF
$anniv_dt = $wc->widget("anniv_dt");
$button = $wc->widget("check_it");
print "Anniversary Date: ", $anniv_dt->html(), "<br>\n";
print $button->html(), "<br>\n";
print "Your anniversary date appears to be: ",
$anniv_dt->value("anniv_dt"), "<br>\n";
print <<EOF;
</form>
</body>
</html>
>> >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 had the hunch that everyone's configuration needs would be different.
Hence the Widget::Config (interface) and Widget::Config::XML (driver)
design. (Thanks for the input.)
>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.
Right. I have many more requirements I eventually want to support
(such as internationalization). The trick is making the design such
that it works in the simple case for simple things, while supporting
advanced features for those who wish to use them. I think it is coming
together pretty well.
>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.
Good points. It is now optional, as long as you provide an alternative
class.
>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.
Right. I absolutely want to support the plain vanilla CGI user as well.
>Thanks,
> Gunther
Stephen
P.S. uh oh. As I am about to send this, I see several more messages have
come in on the thread. I'll check them in a moment.
