[PW-dev] Widget-0.03

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi,

There is a new snapshot of the Perl Widget Library (all available in CVS):
Widget-0.03.  You can download it from

   http://www.officevision.com/pub/Widget/

This achieves a couple major milestones.  As per the Changes file, this 
release includes:

   1. demonstrate that the Perl Widget Library works with the Template Toolkit
   2. add overriding of <widgetType> attributes at the <widget> level
   3. incorporate a "container" concept into widgets, and event bubbling
   4. incorporate concepts of attribute absorption (inheritance, in a
container sense)
   5. implied containers using dots (.) in name (i.e. "birth_dt" is implied
container for "birth_dt.day")
   6. change all attributes from "dash" to "internal capital"
("background-color" to "backgroundColor")
   7. rework the DateDropDowns widget to use dynamic (not pre-configured)
sub-widgets

This release is what I would call the first genuinely usable release.
I am beginning to use it in my projects.
Notably lacking are the yet-to-be-added features of

   A. default configuration file is Perl
   B. multi-lingual widgets (it's coming soon)

Again, the documentation is way out of date, but I have a liberal dose of
examples
in the distribution, so using the Widgets should be easier from both CGI
programs
and Template Toolkit templates.  Mod_perl support is not complete, but it
might
work fine with Apache::Registry.

I am going out of town for two weeks until July 10, so there will be *very*
little activity from me on this project until then.  Expect a Widget-0.10
near the end of July.  At that time, I will be ready to announce the
availability
of the Perl Widget Library to the modperl list and the Template Toolkit list.

1. PWL AND TEMPLATE TOOLKIT

I have created a script in the cgi-bin directory called "ptp", for
"Perl Template Pages" (as opposed to JSP for "Java Server Pages").
It is a general purpose CGI template driver through which I demonstrate
the templates I've written.

I have created sample templates in the "templates" directory.
You can see them in operation here.

   http://www.officevision.com/cgi-bin/pub/Widget/ptp/

If you use the LOAD_PERL option in your template processor, you can use the
following syntax in your templates.

   <html>
   <head><title>Widget Demo</title></head>
   <body>
   <form method='POST'>
   [% USE wc = Widget %]

   [% CALL wc.state.value("w001","Hello") %]

   [%
      wc.widget(
         name = "w001",
         widgetClass = "Widget::HTML::TextField",
         backgroundColor = "#ffa0a0",
         size = 24,
      ).display 
   %]

   </form>
   </body>
   </html>

This usage does not require a config file at all.
(The limitations to this usage become apparent for more complex,
active widgets, and they are overcome by using the config file.)
Take a look at the examples for more information.

I probably will write a proper plugin for the Template Toolkit
sometime, but this gets us by for now.

Note that if the configuration file is used and there are no
overrides in the template, the syntax for displaying a widget
reduces to:

   [% wc.widget("w001").display %]

This is not as simple as we would like it, but it's not too bad

2. CONFIG PRECEDENCE

The configuration of each widget is now assembled by the controller
and cached for each widget.

The widget config is a simple hash which is the result of several
complementary sources:

   1. config of the widget (in Config) (which override widgetType)
   2. optional config of the widget's widgetType (in Config)
   3. config of container widget
   4. args to the widget_config() call, usually coming from the widget 
      constructor. some of these are defaults, other are overrides.

This more sophisticated configuration management paves the way for
themes and internationalization, because widgets absorb attributes
from their container.

See Widget::Controller->widget_config() for more details.

3. STYLES

CSS style sheet attributes are now being supported (such as backgroundColor
of TextField (<input type=text>) widgets.  However, you can expect
significant rework here.  I am not content with the overhead it imposes
on widgets that don't have style sheet attributes.

One of my major design principles is:

   As we make widgets feature-rich, we must not put an undue processing
   burden on users who choose to use only a small number of the features.
   The additional burden should be a simple check to see if a feature
   needs to be invoked based on a single configuraton attribute.

Much more to come on styles...

4. ATTRIBUTE ABSORPTION

This is a major new feature.  Absorption is how element widgets gain the
attribute values of their container widgets.  It is to be distinguished
from attribute *inheritance*, where a child widget inherits data and 
behavior (in an OO sense) from its parent widget class.

5. CONTAINERS AND IMPLIED CONTAINERS
A widget can be made an element of a containing widget by specifying the
"container" argument.  Alternatively, if a widget name has a "." in it
and no other container has been supplied, it is assumed to be contained
by the implied widget.  
(i.e. "birth_dt" is implied container for "birth_dt.day")

6. ATTRIBUTES USE INTERNAL CAPITALS LIKE JAVASCRIPT

Per Cees Hek's good suggestion, I use the Javascript convention for
referring to multi-word attributes, including CSS attributes which have
a dash separating the words. (i.e. "background-color" is "backgroundColor")

7. COMPOUND WIDGETS CAN USE DYNAMIC SUB-WIDGETS

It's taken me this long to catch up to Cees Hek's good observation that
subwidgets created from compound widgets (such as Widget::HTML::DateDropDowns)
should not need to be configured in the config file.

8. EXISTING WIDGETS NOT YET VERY EXCITING

Please note that in accordance with my promise at the outside, the widgets
available for use are actually very limited.  I am getting the plumbing
right before plunging into really interesting widgets.  I have done a little
prototyping with a TreeView widget.  See the non-active, visual prototype at

   http://www.officevision.com/pub/Widget/treedemo.html

It's when we get widgets like this that I believe the promise of the 
Perl Widget Library really begins to become reality.

See the TODO list for other things that are on my mind for releases
yet to come.

Feedback is welcome and appreciated, but please don't expect much
response for 2-1/2 weeks.

Thanks,

Stephen