perl-widget-developer

Re: [PW-dev] OReilly Conference

[James G S. <JG...@TA...>]

Gunther Birznieks <gu...@ex...> wrote:
>How many of you will be at the O'Reilly Conference next month?

I should be there.

>Should we hold a Widget BOF?

Sounds good to me -- do we want it for just this project or for Perl 
templating projects in general?

I can see merit in both -- if we stick to just this project, it is a kind of 
`summit' where we can hash out details and perhaps interest people that might 
use it eventually; if we make it general, we might get good 
cross-fertilization (as if that couldn't happen on the mod_perl list :/ ).
-- 
James Smith <JG...@TA...>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix

Re: [PW-dev] OReilly Conference

[Stephen A. <ste...@of...>]

>Gunther Birznieks <gu...@ex...> wrote:
>How many of you will be at the O'Reilly Conference next month?

Hmmm.
I won't be there.
However, maybe it would be good to set a target for a code
snapshot by that date.  That might give more concrete things
to talk about.

What features should be in Widget-0.10 (the O'Reilly snapshot)?

Stephen

Re: [PW-dev] OReilly Conference

[Gunther B. <gu...@ex...>]

At 11:38 AM 6/12/2001 -0400, Stephen Adkins wrote:
> >Gunther Birznieks <gu...@ex...> wrote:
> >How many of you will be at the O'Reilly Conference next month?
>
>Hmmm.
>I won't be there.
>However, maybe it would be good to set a target for a code
>snapshot by that date.  That might give more concrete things
>to talk about.
>
>What features should be in Widget-0.10 (the O'Reilly snapshot)?

I think a widget controller that understands how to get data from a db and 
optionally from Apache::Session would be quite cool for a next milestone 
since it appears there are several proof of concept widgets already developed.

However, I think it would also be reasonable to use the session to discuss 
stuff on a whiteboard (eg object diagrams) of how some of the more advanced 
features that were discussed are to be implemented.

And I'd like to hear from template authors on how they think they would 
best like to see widgets integrated into their systems.

I wish I had more time. I am afraid that I am knee deep in Java for the 
next month before the conference. My Perl time only comes back in August 
after I get back.

Later,
     Gunther

[PW-dev] Widget-0.03

[Stephen A. <ste...@of...>]

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

[PW-dev] Conferences

[Gunther B. <gu...@ex...>]

Some of you I think mentioned being at the YAPC-Montreal. Just wondering 
how that went. Did any of you get to meet up?

I am still planning on being at O'Reilly Con in another couple of weeks for 
anyone going there.

Later,
    Gunther

[PW-dev] Re: Widget-0.03

[Gunther B. <gu...@ex...>]

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/

Re: [PW-dev] Re: Widget-0.03

[Stephen A. <ste...@of...>]

At 11:19 PM 7/8/2001 +0800, Gunther Birznieks wrote:
>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?
>
...

Hi,

Short answer is...

  where: It is transformed in Widget::HTML::Stylizable
         See the translation table in %style_attrib.
         (It is not convention magic which changes internal caps to
         dashes.) (Please note that the next version, 0.04, will
         probably change the way I implement styles.)

  why:   I needed to choose some convention for multi-word attributes,
         and the internal-caps style (backgroundColor) works with
         named parameter conventions (-backgroundColor => '#ffffff')
         (with no quotes) whereas internal dashes do not 
         (-background-color => '#ffffff') (which fails because "dash"
         is the "minus" operator).

The longer answer includes the following discussion:

  What should the attribute be called in the Perl API (the Perl
     Widget Library) if it maps directly to an attribute of an underlying
     physical rendering technology?

Example:

The background color of something might be translated into

   * bgcolor (HTML of <body>, <td>)
   * background-color (CSS style sheets and HTML STYLE='background-color:
#ffffff')
   * backgroundColor (Javascript method of setting the attribute)

There are any number of rendering technologies which may be used by a given
widget.  However, we should not need to know the particulars about it.
Therefore, we should scan the potention rendering technologies (for naming
precedents so that we don't add yet another naming precedent for no reason).
Then we should *adopt* that convention as the *native* convention for the
attributes of widgets in the PWL.

Therefore, I chose the Javascript-style internal-caps convention for all
PWL attributes because:

 a. it mirrors a commonly used internal rendering technology (Javascript)
 b. it works with Perl for named parameter syntax

Stephen

[PW-dev] YAPC America::North

[Jay L. <Ja...@La...>]

Personally, I can't justify the expense of the O'Reilly conference but will
be heading next door to Montreal for the YAPC conference tomorrow. I know it
is a bit late but if anyone else is there - see ya!

Back on Monday.

J

----- Original Message -----
From: "James G Smith" <JG...@TA...>
To: <per...@li...>
Sent: Tuesday, June 12, 2001 11:27 AM
Subject: Re: [PW-dev] OReilly Conference


> Gunther Birznieks <gu...@ex...> wrote:
> >How many of you will be at the O'Reilly Conference next month?
>
> I should be there.
>
> >Should we hold a Widget BOF?
>
> Sounds good to me -- do we want it for just this project or for Perl
> templating projects in general?
>
> I can see merit in both -- if we stick to just this project, it is a kind
of
> `summit' where we can hash out details and perhaps interest people that
might
> use it eventually; if we make it general, we might get good
> cross-fertilization (as if that couldn't happen on the mod_perl list :/ ).
> --
> James Smith <JG...@TA...>, 979-862-3725
> Texas A&M CIS Operating Systems Group, Unix
>
>
>
> _______________________________________________
> Perl-widget-developer mailing list
> Per...@li...
> http://lists.sourceforge.net/lists/listinfo/perl-widget-developer
>

Re: [PW-dev] YAPC America::North

[Cees H. <ce...@si...>]

On Tue, 12 Jun 2001, Jay Lawrence wrote:

> Personally, I can't justify the expense of the O'Reilly conference but will
> be heading next door to Montreal for the YAPC conference tomorrow. I know it
> is a bit late but if anyone else is there - see ya!

These things always happen when I am away...  I used to live in Toronto,
but I'm in Sydney on a 2 year contract right now.  Does anyone know if
there will be a perl conference in Sydney (or somewhere in Australia) at
some point???

Cees

Re: [PW-dev] OReilly Conference

[Gunther B. <gu...@ex...>]

At 10:27 AM 6/12/2001 -0500, James G Smith wrote:
>Gunther Birznieks <gu...@ex...> wrote:
> >How many of you will be at the O'Reilly Conference next month?
>
>I should be there.

Great!

> >Should we hold a Widget BOF?
>
>Sounds good to me -- do we want it for just this project or for Perl
>templating projects in general?
>
>I can see merit in both -- if we stick to just this project, it is a kind of
>`summit' where we can hash out details and perhaps interest people that might
>use it eventually; if we make it general, we might get good
>cross-fertilization (as if that couldn't happen on the mod_perl list :/ ).

I think both could be fine. I think the ideas and abstractions seem firm 
enough now that the template authors should not be bored.