perl-widget-developer — Discussion about bugs and further development of Perl Widgets

[PW-dev] XML configuration

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

I have an XML configuration object created.  It is a bit awkward 
in places, but this is my first time to deal with XML::Parser 
directly, so someone might have a better way to do this.

The code for this and an example perl script and configuration file 
are at http://hex.tamu.edu/pwl/ .  Documentation is lagging horribly.

Basically, the following is a configuration:

<classes>
  <class id="menu">
    <entrees><hash>
      <a>Aardvark</a>
      <b>Beef</b>
      <c>Calamari</a>
     </hash>
    </entrees>
    <entree>b</entree>
    <desserts><array>
      <value>Chocolate Mousse</value>
      <value>Strawberry Shortcake</value>
      <value>Death by Chocolate</value>
     </array>
    </desserts>
    <dessert>Death by Chocolate</dessert>
  </class>
</classes>

This allows for a widget to have the class "menu".  If the name 
of the class is "entree", then the set of values it can have is 
"entrees" within the "menu" class.  The default value is "entree".

We might want to expand the configuration to something like this:

<configuration>
  <classes>
    <class id="error">
      <color>red</color>
    </class>
  </classes>

  <widgets>
    <widget name="date">
      <month value="January"/>
      <day value="2"/>
      <year>1992</year>
    </widget>
  </widgets>
</configuration>

I don't have that coded yet....


I was wanting the following line to work:

my $conf = read Widget::Configuration::XML "test.conf";

but Perl didn't like it :(  It does make for a nice sentence though.

Instead, I use:

 my $conf = Widget::Configuration::XML -> read("test.conf");

--
James Smith <JG...@TA...>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix

[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

Re: [PW-dev] parameter names (dash, underscore, none)

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

At 01:56 PM 6/19/01 -0500, James G Smith wrote:
>Stephen Adkins <ste...@of...> wrote:
> >At 11:32 AM 6/19/2001 -0500, James G Smith wrote:
> >>Stephen Adkins <ste...@of...> wrote:
> >...
> >>It would be nice to make the translation easy on the code which means
> >choosing
> >>a substitute character...  Perhaps a period `.' ?
> >>
> >>$last_name = $wc -> widget(
> >>      -border.style => "solid",
> >>) -> html();
> >
> >James.  I liked the suggestion better than the underscore (_) I was using,
> >but the "." is the concatenation operator, resulting in the same as:
> >
> >$last_name = $wc -> widget(
> >      -borderstyle => "solid",
> >) -> html();
> >
> >So, I'm sticking with underscores. ;-(
>
>doh!

What does CGI.pm do? Why don't we just go with that and stick with it. I 
think adding the underscores can be done later, but it's very hard to take 
away an API once it's been added.

Of course CGI.pm has an interesting philosophy of automagically taking 
params that it doesn't know about it making them attributes of the 
generated HTML, so that is an interesting feature/utility for a widget.

Later,
    Gunther

Re: [PW-dev] parameter names (dash, underscore, none)

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

On Tue, 19 Jun 2001, Stephen Adkins wrote:

> Hi,
> 
> I continue to work on the next mini-release of the 
> Perl Widget Library.  I have incorporated a number
> of parameters from style sheets such as "border-style", etc.
> 
> Usage looks like this.
> 
> $last_name  = $wc->widget(
>       -name  => "last_name",
>       -widget_class => "Widget::HTML::TextField",
>       -size  => 8,                 # from HTML spec
>       -maxlength => 18,            # from HTML spec
>       -color => "#6666CC",         # from CSS spec
>       -font_size => "10px",        # from CSS spec
>       -border_style => "solid",    # from CSS spec
>       -border_width => "1px",      # from CSS spec
>       -border_color => "#6666CC",  # from CSS spec
>       -padding => "2px",           # from CSS spec
>       -background_color => "#ccffcc",           # from CSS spec
>       -font_family => "Verdana, Geneva, Arial", # from CSS spec
>       -override => 1,              # increase precedence of options to
> "override" from "default"
>       -validate => "date",         # "date", "time", "datetime", "enum",
> "number", "integer", ":regexp"
>    )->html();
> 
> However, this presents a stylistic dilemma with parameter names.
> If I use "border-style", the syntax would be
> 
> $last_name = $wc->widget(
>       -border-style => "solid",
> )->html();
> 
> However, this fails because "-border-style" cannot be a bareword.
> I have so far opted to changed dashes in attribute names to underscores.
> This is the first option.

I think in these situations it is best to look at solutions that other
developers have opted for.  Personallly, I don't like underscores.  That
is how I define private menthods, so it just doesn't seem right.  Also,
since the CGI.pm module uses '-', it could confuse people.  When do i use
_ and when do I use -.

JavaScript has this same problem with stylesheets and accessing styles
from within code.  They opted for removing the middle dash and using an UC
letter (ie -border-style becomes -borderStyle).

I think it is more user-friendly to be consistent with related languages
and modules in this case (people are likely to use a mix of Widget.pm,
CGI.pm and Javascript in the same project), then to come up with yet
another different way of doing things.

Cees

Re: [PW-dev] parameter names (dash, underscore, none)

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

Stephen Adkins <ste...@of...> wrote:
>At 11:32 AM 6/19/2001 -0500, James G Smith wrote:
>>Stephen Adkins <ste...@of...> wrote:
>...
>>It would be nice to make the translation easy on the code which means
>choosing 
>>a substitute character...  Perhaps a period `.' ?
>>
>>$last_name = $wc -> widget(
>>      -border.style => "solid",
>>) -> html();
>
>James.  I liked the suggestion better than the underscore (_) I was using,
>but the "." is the concatenation operator, resulting in the same as:
>
>$last_name = $wc -> widget(
>      -borderstyle => "solid",
>) -> html();
>
>So, I'm sticking with underscores. ;-(

doh!
-- 
James Smith <JG...@TA...>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix

Re: [PW-dev] parameter names (dash, underscore, none)

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

At 11:32 AM 6/19/2001 -0500, James G Smith wrote:
>Stephen Adkins <ste...@of...> wrote:
...
>It would be nice to make the translation easy on the code which means
choosing 
>a substitute character...  Perhaps a period `.' ?
>
>$last_name = $wc -> widget(
>      -border.style => "solid",
>) -> html();

James.  I liked the suggestion better than the underscore (_) I was using,
but the "." is the concatenation operator, resulting in the same as:

$last_name = $wc -> widget(
      -borderstyle => "solid",
) -> html();

So, I'm sticking with underscores. ;-(

Stephen

>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] parameter names (dash, underscore, none)

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

At 11:38 AM 6/19/2001 -0500, you wrote:
>Stephen Adkins <ste...@of...> wrote:
>>Hi,
>>
>>I continue to work on the next mini-release of the 
>>Perl Widget Library.  I have incorporated a number
>>of parameters from style sheets such as "border-style", etc.
>
>I understand the desire to make widgets as configurable as possible, but
do we 
>want to encourage HTML specific configuration that could be left to a style 
>sheet?

I am currently interested in providing many options to the developer.
I do believe that the *better* way is to put this information in a style
sheet.
As the library develops, I think we will learn what is the *best* way to do
it.

I have also completed "container attribute absorption".
This allows for a widget to "absorb" attributes from its container.
This paves the way for themes, languages, etc.

I use the terminology: "an element absorbs attributes from its container"
to distinguish it from inheritance, where: "a child class inherits attributes
from its parent class".

>Something I've been toying with is being able to specify a class for the 
>widget (not in the Perl module sense).  This class would indicate a general 
>set of default attribute values from a configuration file or other source.  
>This could also be used as the class of the object in a CSS file for HTML 
>environments.

Interesting...

>This allows for the coder to not have to worry about those elements
explicitly 
>in the code.  This also allows for configuration files to not have to be 
>specific to a particular named widget.  This also allows for styles to be 
>specified in a general fashion without regard for environment.

My whole vision for the Perl Widget Library is that the programmer will *not*
use the usage I described, where many parameter values of the widgets are
supplied
in the code.  Rather, preferred usage is 

   $last_name = $wc->widget("last_name");

and all of the details are included in configuration files (which would
include
style sheets).

>I don't have configuration code done yet in my sample implementation, but
I'll 
>try to get that done this week to illustrate how this could work.

By the way, when I get to a point where I am content with the basic plumbing
of the prototype, I look forward to evaluating the alternative prototype you
are developing.  I don't mean to be ignoring it.  Thanks for your active 
involvement.

>James Smith <JG...@TA...>, 979-862-3725
>Texas A&M CIS Operating Systems Group, Unix

Stephen

Re: [PW-dev] parameter names (dash, underscore, none)

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

Stephen Adkins <ste...@of...> wrote:
>Hi,
>
>I continue to work on the next mini-release of the 
>Perl Widget Library.  I have incorporated a number
>of parameters from style sheets such as "border-style", etc.

I understand the desire to make widgets as configurable as possible, but do we 
want to encourage HTML specific configuration that could be left to a style 
sheet?

Something I've been toying with is being able to specify a class for the 
widget (not in the Perl module sense).  This class would indicate a general 
set of default attribute values from a configuration file or other source.  
This could also be used as the class of the object in a CSS file for HTML 
environments.

This allows for the coder to not have to worry about those elements explicitly 
in the code.  This also allows for configuration files to not have to be 
specific to a particular named widget.  This also allows for styles to be 
specified in a general fashion without regard for environment.

I don't have configuration code done yet in my sample implementation, but I'll 
try to get that done this week to illustrate how this could work.
-- 
James Smith <JG...@TA...>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix

Re: [PW-dev] parameter names (dash, underscore, none)

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

Stephen Adkins <ste...@of...> wrote:
>However, this presents a stylistic dilemma with parameter names.
>If I use "border-style", the syntax would be
>
>$last_name = $wc->widget(
>      -border-style => "solid",
>)->html();
>
>However, this fails because "-border-style" cannot be a bareword.
>I have so far opted to changed dashes in attribute names to underscores.
>This is the first option.
>
>Alternatively, the second option is to remove the dash like so.
>
>$last_name = $wc->widget(
>      -borderstyle => "solid",
>)->html();
>
>Alternatively, the third (and least attractive option to me) is to 
>require the programmer to quote the named parameter like so.
>
>$last_name = $wc->widget(
>      "-border-style" => "solid",
>)->html();
>
>I have chosen option #1.
>How do you all feel?

It would be nice to make the translation easy on the code which means choosing 
a substitute character...  Perhaps a period `.' ?

$last_name = $wc -> widget(
      -border.style => "solid",
) -> html();
-- 
James Smith <JG...@TA...>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix

[PW-dev] parameter names (dash, underscore, none)

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

Hi,

I continue to work on the next mini-release of the 
Perl Widget Library.  I have incorporated a number
of parameters from style sheets such as "border-style", etc.

Usage looks like this.

$last_name  = $wc->widget(
      -name  => "last_name",
      -widget_class => "Widget::HTML::TextField",
      -size  => 8,                 # from HTML spec
      -maxlength => 18,            # from HTML spec
      -color => "#6666CC",         # from CSS spec
      -font_size => "10px",        # from CSS spec
      -border_style => "solid",    # from CSS spec
      -border_width => "1px",      # from CSS spec
      -border_color => "#6666CC",  # from CSS spec
      -padding => "2px",           # from CSS spec
      -background_color => "#ccffcc",           # from CSS spec
      -font_family => "Verdana, Geneva, Arial", # from CSS spec
      -override => 1,              # increase precedence of options to
"override" from "default"
      -validate => "date",         # "date", "time", "datetime", "enum",
"number", "integer", ":regexp"
   )->html();

However, this presents a stylistic dilemma with parameter names.
If I use "border-style", the syntax would be

$last_name = $wc->widget(
      -border-style => "solid",
)->html();

However, this fails because "-border-style" cannot be a bareword.
I have so far opted to changed dashes in attribute names to underscores.
This is the first option.

Alternatively, the second option is to remove the dash like so.

$last_name = $wc->widget(
      -borderstyle => "solid",
)->html();

Alternatively, the third (and least attractive option to me) is to 
require the programmer to quote the named parameter like so.

$last_name = $wc->widget(
      "-border-style" => "solid",
)->html();

I have chosen option #1.
How do you all feel?

Stephen

[PW-dev] sample implementation

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

I have a tarball available of some stuff I threw together...

http://hex.tamu.edu/pwl/

State doesn't work yet, but the stubs are there.  This gives some 
idea of what I've been thinking about in the design and possible 
implementation aspects.  Documentation is a bit sketchy, but I've 
tried to put together enough to give some idea of how things work.
--
James Smith <JG...@TA...>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix

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.

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

Re: [PW-dev] OReilly Conference

[Issac G. <ne...@wr...>]

> How many of you will be at the O'Reilly Conference next month?
  Unfortunately, though I wanted to, I won't be making it :-(
> Should we hold a Widget BOF?
> 
> Later,
>      Gunther

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

[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] 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

[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

[PW-dev] OReilly Conference

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

How many of you will be at the O'Reilly Conference next month?

Should we hold a Widget BOF?

Later,
     Gunther

Re: [PW-dev] Static methods - was Widget factory

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

At 09:49 AM 6/12/01 +0200, Issac Goldstand wrote:
> > At 05:08 PM 6/11/2001 -0500, you wrote:
> > >"Jay Lawrence" <Ja...@La...> wrote:
> > >>James and Stephen,
> > >>
> > >>Could you please expand on what you mean by static methods?
> > >
> > >These would be methods that are not tied to an instance -- the `new'
>method
> > >(basically, any constructor) is an example of a usually static method.
>Any
> > >method that requires an instance of an object class is not a static
>method.
> > >
> > >Perl blurs the line between static and non-static methods.  C++ is very
> > >explicit and requires the `static' keyword before the function
>declaration.
> > >
> > >The static methods do not have an object to get any information from, so
>any
> > >configuration information they get would have to either come from the
> > function
> > >arguments or from globals.
> > >--
> > >James Smith <JG...@TA...>, 979-862-3725
> > >Texas A&M CIS Operating Systems Group, Unix
> > >
> >
> > James is correct on all points.
> > For example
> >
> >    $wc = Widget->controller();
> >
> > is a "static" method on the Widget package.  No instance of a "Widget"
>class
> > was required in order to call the controller() method.  Any routine called
> > from the package name (i.e. Package::Name->method_name()) is a static
>method.
> > (The terminology indeed comes from C++ and Java.)
> >
> > A "normal" method call (dynamic?) is called on an instance of a class.
>i.e.
> >
> >    $query = CGI->new();       # this is a static method call, called from
> > package
> >    print $query->param("x");  # this is a normal (dynamic) method call,
> > called from object
> >
> > The "Factory" pattern is a standard way of constructing objects without
> > knowing
> > what type of objects they actually are.  In order to instantiate an
>object,
> > you
> > normally need to know the class of the object.  With a factory, you can
>let
> > the
> > factory decide.  In this way,
> >
> >    $wc = Widget->controller();
> >
> > is letting the static method, "controller()", in the Widget package decide
> > which
> > class it should instantiate when returning a Controller.
> > Similarly, with
> >
> >    $date_widget = $wc->widget("date");
> >
> > we are letting the controller decide (based on config and runtime
>information)
> > what actual class to instantiate.
> >
> > Thus, both the Widget package and Widget::Controller objects are acting as
> > factories
> > in the PWL.
> >
> > Stephen
>
>Wait a second... I was under the impression that the Widget::COntroller
>object simply got "bound" to a top level Widget object somewhere...  That
>you couldn't actually go about creating the actual Widgets until you had an
>instantiated Controller....  Am I barking up wrong trees here???

I also think the controller should be instantiated. I plan on having a 
controller that is very different from the controller that I imagine the 
localization folks and other more powerful flexible feature people need to 
have while keeping the widgets simple.

By the way, having static methods also is closely tied to the idea of a 
Singleton design pattern (which can be implemented as either a class static 
methods or as an instantiation that uses a static to realize it's already 
been instantiated once).

Re: [PW-dev] Template Toolkit concept

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

This is just theoretical - I am examining what Gunther was driving at....

I am not sure if I like it, tho. I really really wanna just put in my
templates
simple things like [% widget1 %] to have widget named Widget1 show up there.

This can be accomplished now with little difficulty.

I can see the merits of the widget controller now. It might be attractive to
explore passing the widget controller to Template toolkit and take your
approach of  [% wc.widget1 %] for placing widgets.

I am thinking of overhead for setting my my template variables - if I place
each widget into my $vars hash which I send to my template then that's
a lot of overhead. If I constantly have to get Template Toolkit to parse
[% wc.xxx %] that's even more overhead. A future optimization in TT
would be attractive.

J
----- Original Message -----
From: "Stephen Adkins" <ste...@of...>
To: <per...@li...>
Sent: Tuesday, June 12, 2001 7:26 AM
Subject: Re: [PW-dev] Template Toolkit concept


> At 10:25 AM 6/11/2001 -0400, you wrote:
> >> At 11:09 AM 6/6/2001 -0400, Stephen Adkins wrote:
> >> >At 09:53 AM 6/6/2001 -0400, Jay Lawrence wrote:
> ...
> >> In Java I am used to JSPs and we code widgets using taglibs. So the
> >widgets
> >> are objects, but then there is a widget taglib that can display a
widget.
> >>
> >> <widget id='fname'/>
> >>
> >> in JSP parlance for example.
> >
> >So, for example, with Template Toolkit might we have something like:
> >
> >    [% WIDGET fname %]
> >
> >Which would render the widget in place - and of course you could do
things
> >like [% WIDGET fname.value('Jay') %] if you wanted to set it in your
> >template code.
>
> Jay,
>
> Have you written any Template Toolkit specific driver yet to do this?
> Or is this example just theoretical?
>
> Stephen
>
>
>
> _______________________________________________
> Perl-widget-developer mailing list
> Per...@li...
> http://lists.sourceforge.net/lists/listinfo/perl-widget-developer
>

Re: [PW-dev] Re: [Perl-widget-developer] XML in general

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

At 10:16 AM 6/11/2001 -0400, you wrote:
>I think we can all safely say that XML is an application developer's choice
>and won't be part of the core Widget development effort - but rather an
>important
>side project if people want to use XML to create and control widgets.
>
>Agreed?
>
>Jay

XML in the usage that Matt mentions belongs more in the AxKit realm.
The Widget approach is a different approach.

However, I am using XML as a configuration file format.
It will not be the default configuration file format (changing over to
native perl at the list's request), but it will be a standard option.

Stephen

Re: [PW-dev] Template Toolkit concept

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

At 10:25 AM 6/11/2001 -0400, you wrote:
>> At 11:09 AM 6/6/2001 -0400, Stephen Adkins wrote:
>> >At 09:53 AM 6/6/2001 -0400, Jay Lawrence wrote:
...
>> In Java I am used to JSPs and we code widgets using taglibs. So the
>widgets
>> are objects, but then there is a widget taglib that can display a widget.
>>
>> <widget id='fname'/>
>>
>> in JSP parlance for example.
>
>So, for example, with Template Toolkit might we have something like:
>
>    [% WIDGET fname %]
>
>Which would render the widget in place - and of course you could do things
>like [% WIDGET fname.value('Jay') %] if you wanted to set it in your
>template code.

Jay,

Have you written any Template Toolkit specific driver yet to do this?
Or is this example just theoretical?

Stephen

Re: [PW-dev] Static methods - was Widget factory

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

At 09:49 AM 6/12/2001 +0200, you wrote:
>> At 05:08 PM 6/11/2001 -0500, you wrote:
>> >"Jay Lawrence" <Ja...@La...> wrote:
...
>> Thus, both the Widget package and Widget::Controller objects are acting as
>> factories
>> in the PWL.
>>
>> Stephen
>
>Wait a second... I was under the impression that the Widget::COntroller
>object simply got "bound" to a top level Widget object somewhere...  That
>you couldn't actually go about creating the actual Widgets until you had an
>instantiated Controller....  Am I barking up wrong trees here???
>
>  Issac

The Widget::Controller is a controller, not a widget.
For more info on what a "controller" is, please see the FAQ.

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

The API is currently set up to require you to instantiate a Controller
before you can successfully instantiate any widgets because it is
through the Controller that you have access to configuration and state
information.

If one of the desired usage variants is to instantiate widgets
*directly*, there would need to be a default global Controller created.

This brings us back to our Teambuilding Exercise #2: Usage ...

 Q. Do we need to be able to do the following?
    (I think this is what Jay is implying.)

    use Widget::HTML::Button;
    $button = Widget::HTML::Button->new (
       -name => "fetch",
       -bgcolor => "#ff0000",
    );

I had intended that this *not* be valid usage because of the globals
it would require.

Rather that all widgets be instantiated via the Controller like so.

    use Widget;
    $wc = Widget->controller();
    $button = $wc->widget (
       -name => "fetch",
       '-widget-class' => "Widget::HTML::Button",
       -bgcolor => "#ff0000",
    );

Stephen

Re: [PW-dev] Static methods - was Widget factory

[Issac G. <ne...@wr...>]

> At 05:08 PM 6/11/2001 -0500, you wrote:
> >"Jay Lawrence" <Ja...@La...> wrote:
> >>James and Stephen,
> >>
> >>Could you please expand on what you mean by static methods?
> >
> >These would be methods that are not tied to an instance -- the `new'
method
> >(basically, any constructor) is an example of a usually static method.
Any
> >method that requires an instance of an object class is not a static
method.
> >
> >Perl blurs the line between static and non-static methods.  C++ is very
> >explicit and requires the `static' keyword before the function
declaration.
> >
> >The static methods do not have an object to get any information from, so
any
> >configuration information they get would have to either come from the
> function
> >arguments or from globals.
> >--
> >James Smith <JG...@TA...>, 979-862-3725
> >Texas A&M CIS Operating Systems Group, Unix
> >
>
> James is correct on all points.
> For example
>
>    $wc = Widget->controller();
>
> is a "static" method on the Widget package.  No instance of a "Widget"
class
> was required in order to call the controller() method.  Any routine called
> from the package name (i.e. Package::Name->method_name()) is a static
method.
> (The terminology indeed comes from C++ and Java.)
>
> A "normal" method call (dynamic?) is called on an instance of a class.
i.e.
>
>    $query = CGI->new();       # this is a static method call, called from
> package
>    print $query->param("x");  # this is a normal (dynamic) method call,
> called from object
>
> The "Factory" pattern is a standard way of constructing objects without
> knowing
> what type of objects they actually are.  In order to instantiate an
object,
> you
> normally need to know the class of the object.  With a factory, you can
let
> the
> factory decide.  In this way,
>
>    $wc = Widget->controller();
>
> is letting the static method, "controller()", in the Widget package decide
> which
> class it should instantiate when returning a Controller.
> Similarly, with
>
>    $date_widget = $wc->widget("date");
>
> we are letting the controller decide (based on config and runtime
information)
> what actual class to instantiate.
>
> Thus, both the Widget package and Widget::Controller objects are acting as
> factories
> in the PWL.
>
> Stephen

Wait a second... I was under the impression that the Widget::COntroller
object simply got "bound" to a top level Widget object somewhere...  That
you couldn't actually go about creating the actual Widgets until you had an
instantiated Controller....  Am I barking up wrong trees here???

  Issac

Internet is a wonderful mechanism for making a fool of
yourself in front of a very large audience.
  --Anonymous

Moving the mouse won't get you into trouble...  Clicking it might.
  --Anonymous

PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B