[PW-dev] Widget-0.03
Status: Alpha
Brought to you by:
spadkins
From: Stephen A. <ste...@of...> - 2001-06-23 18:17:12
|
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 |