[PW-dev] Re: Widget-0.03

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

I pretty much like all of this.

But I don't quite understand where background-color is turned into 
backgroundColor and why. Is the widget code then taking this internal 
capital case and turning it back into background-color when it actually 
generates the HTML?

At 02:22 PM 6/23/2001 -0400, Stephen Adkins wrote:
>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

__________________________________________________
Gunther Birznieks (gun...@eX...)
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/