Thread: [Perl-widget-developer] Teambuilding Exercise #2: Usage
Status: Alpha
Brought to you by:
spadkins
Menu
▾
▴
perl-widget-developer
|
From: Stephen A. <ste...@of...> - 2001-06-05 19:53:08
|
Hi, We have gotten pretty focused over the last 24 hours on guts. I am still working my teambuilding plan, which recognizes that debating the guts is engaging, but it is the last step. This exercise is about defining the usage of widgets. I present here two files. cgi-bin/cgisample a CGI script using widgets cgi-bin/cgisample.xml a configuration file for widgets used Note: These two files are running code in CVS. See http://www.officevision.com/cgi-bin/pub/Widget/cgisample I would encourage others to post sample CGI scripts, templates, and config files that suggest how *they* would like to use widgets. Forget the internals for a moment. ;-) Stephen P.S. I agree with Cees's comments about improving DateDropDowns. shark:/usr/ov/acoc/dev/src/Widget/cgi-bin> more cgisample cgisample.xml :::::::::::::: cgisample :::::::::::::: #!/usr/local/bin/perl -w ############################################################## # cgisample ############################################################## # This is an example of a CGI script that uses the capabilities # of the Perl Widget Library minimally. # It looks like any other perl script which uses the CGI.pm # library. # See 'wexec' for an example of a CGI script that uses # the full capabilities of the Perl Widget Library. ############################################################## use lib "/usr/ov/acoc/dev/src/Widget"; use CGI; $query = new CGI; use Widget; $wc = Widget->controller(-cgi => $query); $wc->process_request(); print <<EOF; Content-type: text/html <head> <title>cgisample</title> </head> <body bgcolor=#ffffff> <h1>cgisample</h1> <hr> <form method='POST'> EOF # Please note that there is *nothing* in this code which indicates what physical # class is used to render each "logical" widget. # When the widget is instantiated, though, it is a physical one. # The controller decided which physical widget it would be based on configuration # information and runtime information (not yet implemented) # There's more than one way to do it... ;-) $first_name = $wc->widget("first_name")->html(); # you can skip the widget and just get its HTML $last_name = $wc->widget("last_name")->html(); $address = $wc->widget( -name => "address", -class => "Widget::HTML::Element", -tag => 'input', -type => 'text', -size => '14', -maxlength => '99', )->html(); $birth_dt = $wc->widget("birth_dt")->html; # of course, you don't need to provide parentheses ... $sex = $wc->widget("sex")->html(); $w_check_it = $wc->widget("check_it"); # or you can get the widget $check_it = $w_check_it->html(); # then get its HTML $anniv_dt = $wc->widget("anniv_dt")->html(); $anniv_dt_value = $wc->widget("anniv_dt")->value(); # you can also do other things to a widget, like get its value # note that $wc caches widget instances, so the previous two lines did use the same physical widget $anniv_dt_value = "" if (!defined $anniv_dt_value); print <<EOF; <table border=0> <tr> <td>First Name: </td><td>$first_name</td> <td>Widget::HTML::Element - a general widget for constructing any HTML element (remember, only the configurer worries about what physical class it is. It's transparent to the programmer)</td> </tr> <tr> <td>Last Name: </td><td>$last_name</td> <td>Widget::HTML::Element</td> </tr> <tr> <td>Birth Date: </td><td>$birth_dt</td> <td>Widget::HTML::Element</td> </tr> <tr> <td>Address: </td><td>$address</td> <td>Widget::HTML::Element (not in config file)</td> </tr> <tr> <td>Sex: </td><td>$sex</td> <td>Widget::HTML::Select</td> </tr> <tr> <td>Anniversary Date: </td><td>$anniv_dt</td> <td>Widget::HTML::DateDropDowns</td> </tr> <tr> <td> </td><td>$check_it</td> <td>Widget::HTML::Button</td> </tr> <tr> <td>Anniversary Date is ... </td><td>$anniv_dt_value</td> <td> (value) </td> </tr> </table> </form> </body> </html> EOF :::::::::::::: cgisample.xml :::::::::::::: <config> <widget name="first_name" tag='input' type='text' size='14' maxlength='99'/> <widget name="last_name" widget-class='Widget::HTML::Element' tag='input' type='text' size='14' maxlength='99'/> <widget name="birth_dt" widget-type='date'/> <widget name="anniv_dt" widget-type='date3'/> <widget name="anniv_dt.year" widget-type='year'/> <widget name="anniv_dt.month" widget-type='month'/> <widget name="anniv_dt.day" widget-type='day'/> <widget name="sex" widget-type='sex'/> <widget name="check_it" widget-type='check_anniv_dt'/> <widget-type name="date" tag='input' type='text' size='14' maxlength='99'/> <widget-type name="date3" widget-class='Widget::HTML::DateDropDowns'/> <widget-type name="sex" widget-class='Widget::HTML::Select' domain='sex'/> <widget-type name="year" widget-class='Widget::HTML::Select' domain='year'/> <widget-type name="month" widget-class='Widget::HTML::Select' domain='month'/> <widget-type name="day" widget-class='Widget::HTML::Select' domain='day'/> <widget-type name="check_anniv_dt" widget-class='Widget::HTML::Button' label=' Check Your Anniversary Date '/> <domain name="sex"> <item name="M" label="Male"/> <item name="F" label="Female"/> </domain> <domain name="year"> <item name="1980"/> <item name="1981"/> <item name="1982"/> <item name="1983"/> <item name="1984"/> <item name="1985"/> <item name="1986"/> <item name="1987"/> <item name="1988"/> <item name="1989"/> <item name="1990"/> <item name="1991"/> <item name="1992"/> <item name="1993"/> <item name="1994"/> <item name="1995"/> <item name="1996"/> <item name="1997"/> <item name="1998"/> <item name="1999"/> <item name="2000"/> <item name="2001"/> <item name="2002"/> <item name="2003"/> <item name="2004"/> <item name="2005"/> <item name="2006"/> <item name="2007"/> <item name="2008"/> <item name="2009"/> </domain> <domain name="month"> <item name="01" label="Jan"/> <item name="02" label="Feb"/> <item name="03" label="Mar"/> <item name="04" label="Apr"/> <item name="05" label="May"/> <item name="06" label="Jun"/> <item name="07" label="Jul"/> <item name="08" label="Aug"/> <item name="09" label="Sep"/> <item name="10" label="Oct"/> <item name="11" label="Nov"/> <item name="12" label="Dec"/> </domain> <domain name="day"> <item name="01"/> <item name="02"/> <item name="03"/> <item name="04"/> <item name="05"/> <item name="06"/> <item name="07"/> <item name="08"/> <item name="09"/> <item name="10"/> <item name="11"/> <item name="12"/> <item name="13"/> <item name="14"/> <item name="15"/> <item name="16"/> <item name="17"/> <item name="18"/> <item name="19"/> <item name="20"/> <item name="21"/> <item name="22"/> <item name="23"/> <item name="24"/> <item name="25"/> <item name="26"/> <item name="27"/> <item name="28"/> <item name="29"/> <item name="30"/> <item name="31"/> </domain> </config> |
|
From: Jay L. <Ja...@La...> - 2001-06-06 13:52:19
|
Widgets in Template Toolkit - QED
Here is something that I prototyped on my own system...
- Just to show exactly how simple I'd like the widgets to appear to the
template user ...
General ideas:
- Create hash of widgets: name => Widget::Object
- Register this with Template::Toolkit somehow
- two places come to mind - in the vars (as I have shown here)
- At Template instantiation
my $tt=Template->new ( { WIDGETS=>$widgetHashRef } );
- Reference widgets solely by name
- I do find the "wc." - "wc.widget" - a bit redundant but understand
its purpose
- instead we can beef up the _dotop sub of Stash to give us what we
want!
- Trained Stash to look for widgets by name and if found call their
"display" method with any parameters supplied in the template
testprg.pl
-------------
use Template;
use Widget::Test;
my $tt=Template->new( { INCLUDE_PATH=>"." } );
# Ya get yer vermin whereever u want - XML, SQL, FooBar
$vars= {
'widgets' => {
'test1' => Widget::Test->new( maximum=>100, current=>10 )
},
'lots' => 'o',
'more' => 'variables',
};
$tt->process("test.html", $vars) ||
die "Failed: ".$tt->error()."\n";
--------------
test.html
--------------
This is a test. <p>
[% test1 %]
--------------
Patch to Template Toolkit 2.02 - Template/Stash.pm
--------------
if (defined($value = $root->{ $item })) {
return $value unless ref $value eq 'CODE'; ## RETURN
@result = &$value(@$args); ## @result
}
# Whacked in widget handler
if (defined $root->{ 'widgets' } && defined
$root->{'widgets'}{$item}) {
return $root->{'widgets'}{$item}->display(@$args);
}
# /Whack
elsif ($lvalue) {
# we create an intermediate hash if this is an lvalue
return $root->{ $item } = { }; ## RETURN
}
|
|
From: Stephen A. <ste...@of...> - 2001-06-06 15:03:26
|
At 09:53 AM 6/6/2001 -0400, Jay Lawrence wrote:
>
>Widgets in Template Toolkit - QED
>
>Here is something that I prototyped on my own system...
> - Just to show exactly how simple I'd like the widgets to appear to the
>template user ...
>
>General ideas:
> - Create hash of widgets: name => Widget::Object
> - Register this with Template::Toolkit somehow
> - two places come to mind - in the vars (as I have shown here)
> - At Template instantiation
> my $tt=Template->new ( { WIDGETS=>$widgetHashRef } );
> - Reference widgets solely by name
> - I do find the "wc." - "wc.widget" - a bit redundant but understand
>its purpose
> - instead we can beef up the _dotop sub of Stash to give us what we
>want!
> - Trained Stash to look for widgets by name and if found call their
>"display" method with any parameters supplied in the template
>
>
>testprg.pl
>-------------
>use Template;
>use Widget::Test;
>
>my $tt=Template->new( { INCLUDE_PATH=>"." } );
>
># Ya get yer vermin whereever u want - XML, SQL, FooBar
>$vars= {
> 'widgets' => {
> 'test1' => Widget::Test->new( maximum=>100, current=>10 )
> },
> 'lots' => 'o',
> 'more' => 'variables',
>};
>
>$tt->process("test.html", $vars) ||
> die "Failed: ".$tt->error()."\n";
Hmmm.
So the "widgets" entry in the stash becomes magic.
Seems unattractive because you need to modify the Template Toolkit itself.
But I every solution I can think of requires more steps in the Templates
page than
I'd like to see as well.
>--------------
>test.html
>--------------
>This is a test. <p>
>[% test1 %]
What do you see as the desirability of making the call program know about the
widgets vs. making the template know about the widgets?
I had envisioned some usage like...
[% USE wc = Widget %]
This is a test. <p>
[% wc.test1 %]
This would need some sort of Template Toolkit driver or a special controller
for Template Toolkit to make the syntax work out this way.
>--------------
>Patch to Template Toolkit 2.02 - Template/Stash.pm
>--------------
> if (defined($value = $root->{ $item })) {
> return $value unless ref $value eq 'CODE'; ## RETURN
> @result = &$value(@$args); ## @result
> }
># Whacked in widget handler
> if (defined $root->{ 'widgets' } && defined
>$root->{'widgets'}{$item}) {
> return $root->{'widgets'}{$item}->display(@$args);
> }
># /Whack
>
> elsif ($lvalue) {
> # we create an intermediate hash if this is an lvalue
> return $root->{ $item } = { }; ## RETURN
> }
>
This is an interesting option.
Please see if you can come up with a way which does not require us to
modify the Template Toolkit to specifically recognize a "magic" variable
in the stash.
Stephen
|
|
From: Cees H. <ce...@si...> - 2001-06-06 23:22:32
|
On Wed, 6 Jun 2001, Stephen Adkins wrote:
> At 09:53 AM 6/6/2001 -0400, Jay Lawrence wrote:
> >
> >Widgets in Template Toolkit - QED
> >
> >Here is something that I prototyped on my own system...
> > - Just to show exactly how simple I'd like the widgets to appear to the
> >template user ...
> >
> >General ideas:
> > - Create hash of widgets: name => Widget::Object
> > - Register this with Template::Toolkit somehow
> > - two places come to mind - in the vars (as I have shown here)
> > - At Template instantiation
> > my $tt=Template->new ( { WIDGETS=>$widgetHashRef } );
> > - Reference widgets solely by name
> > - I do find the "wc." - "wc.widget" - a bit redundant but understand
> >its purpose
> > - instead we can beef up the _dotop sub of Stash to give us what we
> >want!
> > - Trained Stash to look for widgets by name and if found call their
> >"display" method with any parameters supplied in the template
> >
> >
> >testprg.pl
> >-------------
> >use Template;
> >use Widget::Test;
> >
> >my $tt=Template->new( { INCLUDE_PATH=>"." } );
> >
> ># Ya get yer vermin whereever u want - XML, SQL, FooBar
> >$vars= {
> > 'widgets' => {
> > 'test1' => Widget::Test->new( maximum=>100, current=>10 )
> > },
> > 'lots' => 'o',
> > 'more' => 'variables',
> >};
> >
> >$tt->process("test.html", $vars) ||
> > die "Failed: ".$tt->error()."\n";
>
> Hmmm.
> So the "widgets" entry in the stash becomes magic.
> Seems unattractive because you need to modify the Template Toolkit itself.
> But I every solution I can think of requires more steps in the Templates
> page than
> I'd like to see as well.
Also, you want to be able to access a widget's value, not just render
it... I did a quick TT2 test last week with the first code base, and I
thought an easy and very flexable way to use it was as follows:
use Template;
use Widget::Test;
my $tt=Template->new( { INCLUDE_PATH=>"." } );
$vars= {
'test1' => Widget::Test->new( maximum=>100, current=>10 )
'lots' => 'o',
'more' => 'variables',
};
$tt->process("test.html", $vars) ||
die "Failed: ".$tt->error()."\n";
then in you template you could just do:
This is a test widget: [% test1.render %]<br>
And here is it's value [% test1.value %]<br>
This doesn't require any special code in the Widget library or the
Template Toolkit. However, it does require a template designer to know a
little bit about widgets (ie how to render them and get their values)
I had a working example of this, but it is at home (and I am at work). I
can fix it up an post it for comments if everyone wants...
Cees Hek
>
> >--------------
> >test.html
> >--------------
> >This is a test. <p>
> >[% test1 %]
>
> What do you see as the desirability of making the call program know about the
> widgets vs. making the template know about the widgets?
>
> I had envisioned some usage like...
>
> [% USE wc = Widget %]
> This is a test. <p>
> [% wc.test1 %]
>
> This would need some sort of Template Toolkit driver or a special controller
> for Template Toolkit to make the syntax work out this way.
>
> >--------------
> >Patch to Template Toolkit 2.02 - Template/Stash.pm
> >--------------
> > if (defined($value = $root->{ $item })) {
> > return $value unless ref $value eq 'CODE'; ## RETURN
> > @result = &$value(@$args); ## @result
> > }
> ># Whacked in widget handler
> > if (defined $root->{ 'widgets' } && defined
> >$root->{'widgets'}{$item}) {
> > return $root->{'widgets'}{$item}->display(@$args);
> > }
> ># /Whack
> >
> > elsif ($lvalue) {
> > # we create an intermediate hash if this is an lvalue
> > return $root->{ $item } = { }; ## RETURN
> > }
> >
>
> This is an interesting option.
> Please see if you can come up with a way which does not require us to
> modify the Template Toolkit to specifically recognize a "magic" variable
> in the stash.
>
> Stephen
>
>
>
> _______________________________________________
> Perl-widget-developer mailing list
> Per...@li...
> http://lists.sourceforge.net/lists/listinfo/perl-widget-developer
>
>
--
Cees Hek
SiteSuite Corporation
ce...@si...
|
|
From: Gunther B. <gu...@ex...> - 2001-06-11 04:45:20
|
At 08:09 PM 6/7/2001 +1000, Cees Hek wrote:
>On Wed, 6 Jun 2001, Stephen Adkins wrote:
>
> > At 09:53 AM 6/6/2001 -0400, Jay Lawrence wrote:
> > >
> > >Widgets in Template Toolkit - QED
> > >
> > >Here is something that I prototyped on my own system...
> > > - Just to show exactly how simple I'd like the widgets to appear
> to the
> > >template user ...
> > >
> > >General ideas:
> > > - Create hash of widgets: name => Widget::Object
> > > - Register this with Template::Toolkit somehow
> > > - two places come to mind - in the vars (as I have shown here)
> > > - At Template instantiation
> > > my $tt=Template->new ( { WIDGETS=>$widgetHashRef } );
> > > - Reference widgets solely by name
> > > - I do find the "wc." - "wc.widget" - a bit redundant but
> understand
> > >its purpose
> > > - instead we can beef up the _dotop sub of Stash to give us
> what we
> > >want!
> > > - Trained Stash to look for widgets by name and if found call their
> > >"display" method with any parameters supplied in the template
> > >
> > >
> > >testprg.pl
> > >-------------
> > >use Template;
> > >use Widget::Test;
> > >
> > >my $tt=Template->new( { INCLUDE_PATH=>"." } );
> > >
> > ># Ya get yer vermin whereever u want - XML, SQL, FooBar
> > >$vars= {
> > > 'widgets' => {
> > > 'test1' => Widget::Test->new( maximum=>100, current=>10 )
> > > },
> > > 'lots' => 'o',
> > > 'more' => 'variables',
> > >};
> > >
> > >$tt->process("test.html", $vars) ||
> > > die "Failed: ".$tt->error()."\n";
> >
> > Hmmm.
> > So the "widgets" entry in the stash becomes magic.
> > Seems unattractive because you need to modify the Template Toolkit itself.
> > But I every solution I can think of requires more steps in the Templates
> > page than
> > I'd like to see as well.
>
>Also, you want to be able to access a widget's value, not just render
>it... I did a quick TT2 test last week with the first code base, and I
>thought an easy and very flexable way to use it was as follows:
>
>use Template;
>use Widget::Test;
>
>my $tt=Template->new( { INCLUDE_PATH=>"." } );
>
>$vars= {
> 'test1' => Widget::Test->new( maximum=>100, current=>10 )
> 'lots' => 'o',
> 'more' => 'variables',
>};
>
>$tt->process("test.html", $vars) ||
> die "Failed: ".$tt->error()."\n";
>
>then in you template you could just do:
>
>This is a test widget: [% test1.render %]<br>
>And here is it's value [% test1.value %]<br>
>
>
>This doesn't require any special code in the Widget library or the
>Template Toolkit. However, it does require a template designer to know a
>little bit about widgets (ie how to render them and get their values)
>
>I had a working example of this, but it is at home (and I am at work). I
>can fix it up an post it for comments if everyone wants...
This seems OK. I also think the getting the value() will not be oft used
unless you need to encode logic to display a widget only if another widget
has a particular value.
I do prefer a taglibs metaphor as I posted earlier. With taglib support, I
can write a widget iterator that know to populate the widget tag with the
appropriate widget.
eg from one of my JSPs
<view:widgetIterator>
<view:next>
<TD CLASS="FIRST"><widget/></TD>
</view:next>
<view:next>
<TD CLASS="ALTROW"><widget/></TD>
</view:next>
</view:widgetIterator>
Of course, the exact syntax of taglibs can be argued about, but from a
functional level, I find them quite useful encapsulations of code. It's
really wonderful when template languages support something like it and it
goes hand in hand with widgets.
|
|
From: Gunther B. <gu...@ex...> - 2001-06-11 04:33:59
|
At 11:09 AM 6/6/2001 -0400, Stephen Adkins wrote:
>At 09:53 AM 6/6/2001 -0400, Jay Lawrence wrote:
> >
> >Widgets in Template Toolkit - QED
> >
> >Here is something that I prototyped on my own system...
> > - Just to show exactly how simple I'd like the widgets to appear to the
> >template user ...
> >
> >General ideas:
> > - Create hash of widgets: name => Widget::Object
> > - Register this with Template::Toolkit somehow
> > - two places come to mind - in the vars (as I have shown here)
> > - At Template instantiation
> > my $tt=Template->new ( { WIDGETS=>$widgetHashRef } );
> > - Reference widgets solely by name
> > - I do find the "wc." - "wc.widget" - a bit redundant but understand
> >its purpose
> > - instead we can beef up the _dotop sub of Stash to give us what we
> >want!
> > - Trained Stash to look for widgets by name and if found call their
> >"display" method with any parameters supplied in the template
> >
> >
> >testprg.pl
> >-------------
> >use Template;
> >use Widget::Test;
> >
> >my $tt=Template->new( { INCLUDE_PATH=>"." } );
> >
> ># Ya get yer vermin whereever u want - XML, SQL, FooBar
> >$vars= {
> > 'widgets' => {
> > 'test1' => Widget::Test->new( maximum=>100, current=>10 )
> > },
> > 'lots' => 'o',
> > 'more' => 'variables',
> >};
> >
> >$tt->process("test.html", $vars) ||
> > die "Failed: ".$tt->error()."\n";
>
>Hmmm.
>So the "widgets" entry in the stash becomes magic.
>Seems unattractive because you need to modify the Template Toolkit itself.
>But I every solution I can think of requires more steps in the Templates
>page than
>I'd like to see as well.
>
> >--------------
> >test.html
> >--------------
> >This is a test. <p>
> >[% test1 %]
>
>What do you see as the desirability of making the call program know about the
>widgets vs. making the template know about the widgets?
>
>I had envisioned some usage like...
>
> [% USE wc = Widget %]
> This is a test. <p>
> [% wc.test1 %]
>
>This would need some sort of Template Toolkit driver or a special controller
>for Template Toolkit to make the syntax work out this way.
>
> >--------------
> >Patch to Template Toolkit 2.02 - Template/Stash.pm
> >--------------
> > if (defined($value = $root->{ $item })) {
> > return $value unless ref $value eq 'CODE'; ## RETURN
> > @result = &$value(@$args); ## @result
> > }
> ># Whacked in widget handler
> > if (defined $root->{ 'widgets' } && defined
> >$root->{'widgets'}{$item}) {
> > return $root->{'widgets'}{$item}->display(@$args);
> > }
> ># /Whack
> >
> > elsif ($lvalue) {
> > # we create an intermediate hash if this is an lvalue
> > return $root->{ $item } = { }; ## RETURN
> > }
> >
>
>This is an interesting option.
>Please see if you can come up with a way which does not require us to
>modify the Template Toolkit to specifically recognize a "magic" variable
>in the stash.
>
>Stephen
What it sounds to me is that rather than hacking TT in a specific way for
widgets, TT would benefit a lot from a generic taglib hook.
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.
|
|
From: Stephen A. <ste...@of...> - 2001-06-12 11:21:48
|
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
|
|
From: Jay L. <Ja...@La...> - 2001-06-12 14:06:49
|
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
>
|
|
From: Jay L. <Ja...@La...> - 2001-06-11 14:24:20
|
See bottom of message:
> At 11:09 AM 6/6/2001 -0400, Stephen Adkins wrote:
> >At 09:53 AM 6/6/2001 -0400, Jay Lawrence wrote:
> > >
> > >Widgets in Template Toolkit - QED
> > >
> > >Here is something that I prototyped on my own system...
> > > - Just to show exactly how simple I'd like the widgets to appear to
the
> > >template user ...
> > >
> > >General ideas:
> > > - Create hash of widgets: name => Widget::Object
> > > - Register this with Template::Toolkit somehow
> > > - two places come to mind - in the vars (as I have shown here)
> > > - At Template instantiation
> > > my $tt=Template->new ( { WIDGETS=>$widgetHashRef } );
> > > - Reference widgets solely by name
> > > - I do find the "wc." - "wc.widget" - a bit redundant but
understand
> > >its purpose
> > > - instead we can beef up the _dotop sub of Stash to give us
what we
> > >want!
> > > - Trained Stash to look for widgets by name and if found call their
> > >"display" method with any parameters supplied in the template
> > >
> > >
> > >testprg.pl
> > >-------------
> > >use Template;
> > >use Widget::Test;
> > >
> > >my $tt=Template->new( { INCLUDE_PATH=>"." } );
> > >
> > ># Ya get yer vermin whereever u want - XML, SQL, FooBar
> > >$vars= {
> > > 'widgets' => {
> > > 'test1' => Widget::Test->new( maximum=>100, current=>10 )
> > > },
> > > 'lots' => 'o',
> > > 'more' => 'variables',
> > >};
> > >
> > >$tt->process("test.html", $vars) ||
> > > die "Failed: ".$tt->error()."\n";
> >
> >Hmmm.
> >So the "widgets" entry in the stash becomes magic.
> >Seems unattractive because you need to modify the Template Toolkit
itself.
> >But I every solution I can think of requires more steps in the Templates
> >page than
> >I'd like to see as well.
> >
> > >--------------
> > >test.html
> > >--------------
> > >This is a test. <p>
> > >[% test1 %]
> >
> >What do you see as the desirability of making the call program know about
the
> >widgets vs. making the template know about the widgets?
> >
> >I had envisioned some usage like...
> >
> > [% USE wc = Widget %]
> > This is a test. <p>
> > [% wc.test1 %]
> >
> >This would need some sort of Template Toolkit driver or a special
controller
> >for Template Toolkit to make the syntax work out this way.
> >
> > >--------------
> > >Patch to Template Toolkit 2.02 - Template/Stash.pm
> > >--------------
> > > if (defined($value = $root->{ $item })) {
> > > return $value unless ref $value eq 'CODE'; ## RETURN
> > > @result = &$value(@$args); ## @result
> > > }
> > ># Whacked in widget handler
> > > if (defined $root->{ 'widgets' } && defined
> > >$root->{'widgets'}{$item}) {
> > > return $root->{'widgets'}{$item}->display(@$args);
> > > }
> > ># /Whack
> > >
> > > elsif ($lvalue) {
> > > # we create an intermediate hash if this is an lvalue
> > > return $root->{ $item } = { }; ## RETURN
> > > }
> > >
> >
> >This is an interesting option.
> >Please see if you can come up with a way which does not require us to
> >modify the Template Toolkit to specifically recognize a "magic" variable
> >in the stash.
> >
> >Stephen
>
> What it sounds to me is that rather than hacking TT in a specific way for
> widgets, TT would benefit a lot from a generic taglib hook.
>
> 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.
I don't know if it is being discussed but templates don't have a super
friendly way of expressing named parameters. You can do things like [%
WIDGET fname('value','Jay','colour','green','width','20') %] but it might be
more attractive to have a syntax this is clearly name=>"value" or the
like....
I guess the advantage here is that you can abstract how widgets are
instanciated and potentially create efficiency by allowing for widget
instanciation at the time the template is compiled...
Jay
|
|
From: Jay L. <Ja...@La...> - 2001-06-06 14:04:19
|
One other thing I really wanna see is thaw/freeze support. Scary? Not
really. Obviously if you don't wanna thaw and freeze widgets ever this will
be no skin off your nose - it is optional to use.
I belive that one thing needs to happen in the thaw phase - that is a "use"
for the widget's class. There is no guarantee that you've "use"d that widget
class already.
ie/
use Widget;
open DAT, "widget.dat"; undef $/; $widget_dat=<DAT>; close DAT;
my $widget=Widget->thaw($widget_dat);
print $widget->whizbang;
$widget->whizbang( rand );
open DAT, ">widget.dat"; print DAT $widget->freeze; close DAT;
--------
Base class would support serialization of widget properties through
Storable, Data::Dumper and XML.
You might be able to test what format is being thaw'ed but it might be
desirable to pass that info along explicitly:
$widget->freeze('XML', (params for XML generation) );
$widget->freeze('dumper');
$widget->freeze('storable');
$Widget::freezer="storable"; # Over ride default
Cheers,
Jay
|
|
From: Stephen A. <ste...@of...> - 2001-06-06 14:47:03
|
At 10:05 AM 6/6/2001 -0400, Jay Lawrence wrote: >One other thing I really wanna see is thaw/freeze support. Scary? Not >really. Obviously if you don't wanna thaw and freeze widgets ever this will >be no skin off your nose - it is optional to use. > >I belive that one thing needs to happen in the thaw phase - that is a "use" >for the widget's class. There is no guarantee that you've "use"d that widget >class already. > Interesting idea. What is the purpose of freezing and thawing widgets? Stephen |
|
From: Gunther B. <gu...@ex...> - 2001-06-11 02:30:57
|
How do you propose supporting this API-wise? BTW Minor Peeve: For those changing topics -- Please change the subjects in a shorter, more readable fashion when changing topics. Not all mailers support over 60 or so chars of subject so reading this particular thread was kind of a pain for me after coming back to it. Of course, this post was one of the better ones as some didn't bother changing subjects at all. :) At 11:06 AM 6/6/2001 -0400, Jay Lawrence wrote: >The purpose? Ah, good question. More variety of configuration options. I >expect that I'll want to configure my widgets separate from my code. (At >least the types of widgets I'm thinking about) > >So this gives me the option to configure them elsewhere, save them (freeze), >and have my code thaw all the widgets that it cares about. FURTHERMORE, if I >want to give others the chance to configure some or all widgets - I can >allow them to modify the saved definition and resave it as I deem >appropriate. > >The widget has to know how to freeze and thaw itsself because of course that >is implementation dependant to some degree. IE/ Data::Dumper would dump out >the hash that holds all of the widget properties - which in itsself is an >implementation detail. > >Jay > > > At 10:05 AM 6/6/2001 -0400, Jay Lawrence wrote: > > >One other thing I really wanna see is thaw/freeze support. Scary? Not > > >really. Obviously if you don't wanna thaw and freeze widgets ever this >will > > >be no skin off your nose - it is optional to use. > > > > > >I belive that one thing needs to happen in the thaw phase - that is a >"use" > > >for the widget's class. There is no guarantee that you've "use"d that >widget > > >class already. > > > > > > > Interesting idea. > > What is the purpose of freezing and thawing widgets? > > > > Stephen > > > > > > > > >_______________________________________________ >Perl-widget-developer mailing list >Per...@li... >http://lists.sourceforge.net/lists/listinfo/perl-widget-developer __________________________________________________ Gunther Birznieks (gun...@eX...) eXtropia - The Open Web Technology Company http://www.eXtropia.com/ |
|
From: Jay L. <Ja...@La...> - 2001-06-11 14:34:20
|
From: "Gunther Birznieks" <gu...@ex...>
> How do you propose supporting this API-wise?
$stored_data = $widget->freeze;
This should return a data structure (i.e. hash) in a format like Storable or
Data::Dumper of all of the properties of the object that are persistant. I
don't belive that you can just freeze or thaw your runtime object as it
might have extra information that is not suitable for storing. (ie/ object
ref to controller object, etc). Not to mention it is implementation
specific - and if you change your implementation your frozen objects won't
be as easy to recall.
My idea to get this data back might be as follows:
$widget=Widget->new( thaw => $stored_data );
# Will know what class this object is from contents of $stored_data
or
$widget=new Widget::Foo;
$widget->thaw( $stored_data );
# Gotta check that stored_data widget class matches this widget class,
eh?
Just what I had in mind...
> Of course, this post was one of the better ones as some didn't bother
> changing subjects at all. :)
Thanks for noticing.
J
>
> At 11:06 AM 6/6/2001 -0400, Jay Lawrence wrote:
> >The purpose? Ah, good question. More variety of configuration options. I
> >expect that I'll want to configure my widgets separate from my code. (At
> >least the types of widgets I'm thinking about)
> >
> >So this gives me the option to configure them elsewhere, save them
(freeze),
> >and have my code thaw all the widgets that it cares about. FURTHERMORE,
if I
> >want to give others the chance to configure some or all widgets - I can
> >allow them to modify the saved definition and resave it as I deem
> >appropriate.
> >
> >The widget has to know how to freeze and thaw itsself because of course
that
> >is implementation dependant to some degree. IE/ Data::Dumper would dump
out
> >the hash that holds all of the widget properties - which in itsself is an
> >implementation detail.
> >
> >Jay
> >
> > > At 10:05 AM 6/6/2001 -0400, Jay Lawrence wrote:
> > > >One other thing I really wanna see is thaw/freeze support. Scary? Not
> > > >really. Obviously if you don't wanna thaw and freeze widgets ever
this
> >will
> > > >be no skin off your nose - it is optional to use.
> > > >
> > > >I belive that one thing needs to happen in the thaw phase - that is a
> >"use"
> > > >for the widget's class. There is no guarantee that you've "use"d that
> >widget
> > > >class already.
> > > >
> > >
> > > Interesting idea.
> > > What is the purpose of freezing and thawing widgets?
> > >
> > > Stephen
> > >
> > >
> > >
> >
> >
> >_______________________________________________
> >Perl-widget-developer mailing list
> >Per...@li...
> >http://lists.sourceforge.net/lists/listinfo/perl-widget-developer
>
> __________________________________________________
> Gunther Birznieks (gun...@eX...)
> eXtropia - The Open Web Technology Company
> http://www.eXtropia.com/
>
>
> _______________________________________________
> Perl-widget-developer mailing list
> Per...@li...
> http://lists.sourceforge.net/lists/listinfo/perl-widget-developer
>
|
|
From: Jay L. <Ja...@La...> - 2001-06-06 15:05:25
|
The purpose? Ah, good question. More variety of configuration options. I expect that I'll want to configure my widgets separate from my code. (At least the types of widgets I'm thinking about) So this gives me the option to configure them elsewhere, save them (freeze), and have my code thaw all the widgets that it cares about. FURTHERMORE, if I want to give others the chance to configure some or all widgets - I can allow them to modify the saved definition and resave it as I deem appropriate. The widget has to know how to freeze and thaw itsself because of course that is implementation dependant to some degree. IE/ Data::Dumper would dump out the hash that holds all of the widget properties - which in itsself is an implementation detail. Jay > At 10:05 AM 6/6/2001 -0400, Jay Lawrence wrote: > >One other thing I really wanna see is thaw/freeze support. Scary? Not > >really. Obviously if you don't wanna thaw and freeze widgets ever this will > >be no skin off your nose - it is optional to use. > > > >I belive that one thing needs to happen in the thaw phase - that is a "use" > >for the widget's class. There is no guarantee that you've "use"d that widget > >class already. > > > > Interesting idea. > What is the purpose of freezing and thawing widgets? > > Stephen > > > |
Thanks for helping keep SourceForge clean.
X