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

Re: [Perl-widget-developer] XSP PerForm taglib (fwd)

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

My initial reaction is that I think this is much more complex than a widget 
library that produces HTML and it's even less clear to me that XML is a 
good delivery mechanism for abstracting forms.

I truly believe that when you make an app into an HTML app vs a WML app vs 
anything else that the screens are significantly different.

I think that this XML stuff may be fine for content sites like newspapers, 
but for an app it seems like it's a lot of work for much less gain than you 
get on the pure content management side.

Later,
    Gunther

At 10:49 PM 6/8/2001 +0100, Matt Sergeant wrote:
>Thought this might interest some of you widget geeks :-)
>
>--
><Matt/>
>
>     /||    ** Founder and CTO  **  **   http://axkit.com/     **
>    //||    **  AxKit.com Ltd   **  ** XML Application Serving **
>   // ||    ** http://axkit.org **  ** XSLT, XPathScript, XSP  **
>  // \\| // ** mod_perl news and resources: http://take23.org  **
>      \\//
>      //\\
>     //  \\
>
>---------- Forwarded message ----------
>Date: Fri, 8 Jun 2001 22:40:56 +0100 (BST)
>From: Matt Sergeant <ma...@se...>
>To: AxKit Users Mailing List <axk...@ax...>
>Subject: XSP PerForm taglib
>
>Taking a bunch of ideas from a number of places I've started putting
>together what I call the "PerForm" taglib. This is sort of a magic form
>tag library that will enable you to write web forms sucking data from
>various sources more easily.
>
>I'm looking for some sort of feedback on this, though it's pretty funky as
>it stands IMHO.
>
>Best way to describe it is with an example (this assumes passing
>familiarity with XSP):
>
>===============
>
><?xml version="1.0"?>
><xsp:page
>     xmlns:xsp="http://apache.org/xsp/core/v1"
>     xmlns:web="http://axkit.org/NS/xsp/webutils/v1"
>     xmlns:f="http://axkit.org/NS/xsp/perform/v1"
>     language="perl"
>     indent-result="yes"
> >
><!-- TOP LEVEL LOGIC -->
><xsp:logic>
>
># Each function recieves a $ctxt object, which is a hash to
># store things in. It has one entry by default, "Form", which
># is a hash of form values
>
>sub load_title {
>     my ($ctxt, $default, $current) = @_;
>     warn("load_title ($default, $current)\n");
>     return $current || $default;
>}
>
>sub load_link {
>     my ($ctxt, $default, $current) = @_;
>     warn("load_link ($default, $current)\n");
>     return $current || $default;
>}
>
>sub save_title {
>     my ($ctxt, $new_value) = @_;
>     warn("save_title : $new_value\n");
>}
>
>sub save_link {
>     my ($ctxt, $new_value) = @_;
>     warn("save_link : $new_value\n");
>}
>
>sub start_form_create {
>     my ($ctxt, $save_mode) = @_;
>     warn("start_form\n");
>}
>
>sub end_form_create {
>     my ($ctxt, $save_mode) = @_;
>     warn("end_form\n");
>     # if everything is OK, and we're in save_mode, redirect.
>     if ($save_mode) {
>        if ($ctxt->{OK}) {
>          # note mixing taglibs and Perl!!!
>          <web:redirect uri="everything_ok.xsp"/>
>        }
>     }
>}
>
></xsp:logic>
>
>Title:
>Link:
></xsp:page>
>
>===============
>
>OK, hopefully that hasn't confused anyone too much. Now the idea is that
>these forms always get submitted back to themselves. They do their own
>validation. If everything went well and the form got saved OK, they issue
>a redirect to another page. It's kinda like the MVC model, only slightly
>spiced the AxKit way :-)
>
>Now when the form is first loaded, the input fields are populated by a
>callback to the load_<name>() function, where <name> is the name entry of
>the particular form field. So to populate the first textfield, it calls
>load_title(...). It passes in parameters $ctxt, $default, and $current.
>Note that $current will only be filled if this form has already been
>submitted once (filled with the current value, obviously). The value you
>return is what goes in the text box that the user sees.
>
>When the form is submitted, the save_<name>() functions are called. This
>time they are passed the $ctxt and the new value. There you can do
>validation or whatever you like (save to a DB, etc).
>
>Each view of the form is started by a call to start_form_<name>(), where
><name> this time is the name attribute on the form. When all the form's
>callbacks have been performed, the end_form_<name>() callback is called.
>
>The $ctxt object is a simple hashref that you can fill with whatever you
>like. It's there to help you maintain state between the callbacks. It
>contains one entry by default, "Form", which is a hashref to all the other
>form values. This allows you to do validation where one value depends on
>another.
>
>If you *don't* want to supply callbacks for load_*, then it defaults to
>using either the current value (i.e. the value last posted to the form),
>or the default value specified if this is the first load of this form.
>
>Now when all this has been done, it doesn't generate a HTML widget. It
>just generates some XML decorated with all the relevant attributes. You
>need to write an XSLT stylesheet (which I'll include with the package for
>HTML) to render it to HTML. But it's really simple to do that with
>xsl:include/xsl:import. I may even be persuaded to do an XPathScript
>stylesheet for it :-)
>
>I welcome your feedback on this. I think it will make building complex
>forms really easy. One nice thing with XML is we can put all that nasty
>callbacks code in another file, and use entities to load it in. Or we can
>use "use OtherPackage qw(...)" to import the functions to the current
>namespace. Either way will work.
>
>I can put this in CVS if people want to play with it as it stands. But I
>have only implemented the textfield widget as yet.
>
>--
><Matt/>
>
>     /||    ** Founder and CTO  **  **   http://axkit.com/     **
>    //||    **  AxKit.com Ltd   **  ** XML Application Serving **
>   // ||    ** http://axkit.org **  ** XSLT, XPathScript, XSP  **
>  // \\| // ** mod_perl news and resources: http://take23.org  **
>      \\//
>      //\\
>     //  \\
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: axk...@ax...
>For additional commands, e-mail: axk...@ax...
>
>
>
>_______________________________________________
>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/

Re: [Perl-widget-developer] Guesture Pattern was VOTE: display() name

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

1) I am wondering if [Perl-widget-developer] can be shortened to [pwdev] in 
these messages.

2) Here are the URLs:

http://java.sun.com/j2ee/blueprints/design_patterns/model_view_controller/index.html

The whole blueprint chapter is

http://java.sun.com/j2ee/blueprints/introduction/application_scenarios/index.html#1043774

The entire J2EE blue print is

http://java.sun.com/j2ee/blueprints/apmTOC.html


At 12:16 AM 6/11/2001 -0400, Stephen Adkins wrote:
>At 11:30 AM 6/11/2001 +0800, Gunther Birznieks wrote:
> >At 01:56 PM 6/8/2001 -0400, Stephen Adkins wrote:
>...
> >In our Java widget API, we call the state the user is in the "User Gesture"
> >and hence all actions and views get access to the user gesture object which
> >also coincidentally knows what parameters are vital to keep around in order
> >to maintain state. I think it would be appropriate for an HTMLContainer of
> >widgets to know how to generate a state maintenance widget based on a 
> config.
> >
> >Gesture is a pattern that I believe the Java J2EE whitepapers endorse as
> >the mechanism for passing data in a model-view-controller architecture.
>
>Gunther,
>
>Can you point us to some online documentation about the Gesture pattern?
>
>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/

Re: [Perl-widget-developer] Teambuilding Exercise #2: Usage - Template Toolkit concept

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

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.

Re: [Perl-widget-developer] Teambuilding Exercise #2: Usage - Template Toolkit concept

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

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.

[Perl-widget-developer] Guesture Pattern was VOTE: display() name

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

At 11:30 AM 6/11/2001 +0800, Gunther Birznieks wrote:
>At 01:56 PM 6/8/2001 -0400, Stephen Adkins wrote:
...
>In our Java widget API, we call the state the user is in the "User Gesture" 
>and hence all actions and views get access to the user gesture object which 
>also coincidentally knows what parameters are vital to keep around in order 
>to maintain state. I think it would be appropriate for an HTMLContainer of 
>widgets to know how to generate a state maintenance widget based on a config.
>
>Gesture is a pattern that I believe the Java J2EE whitepapers endorse as 
>the mechanism for passing data in a model-view-controller architecture.

Gunther,

Can you point us to some online documentation about the Gesture pattern?

Stephen

Re: [Perl-widget-developer] VOTE: display() name

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

At 01:56 PM 6/8/2001 -0400, Stephen Adkins wrote:
>Hi,
>
>ISSUE #1:
>
>I am requesting a quick vote to put to bed this naming issue.
>I agree that we need a
>
>    $widget->display()
>
>method.
>My ordered votes for what to call it are:
>
>    1. display()
>    2. render()
>    3. show()
>    4. draw()
>
>ISSUE #2 (related):
>
>On HTML widgets, I think there is still a place for an html()
>method.  This method has no parallels in the Gtk or Curses
>widgets.  However, the difference is that calling the html()
>method on an HTML widget simply requests the widget to report
>the HTML that would be used.  Calling the display() method
>(or render() or whatever) is a tacit promise that the HTML
>will be displayed.
>
>This information will be of use in handling the state management.
>Variables in the State which have not been "display()ed" can
>be maintained by creating <input type=hidden> elements.
>
>It is because of this difference between the html() method
>and the display() method that "display()" seems better to me
>than "render()".
>
>Please vote... or *forever* hold your peace.
>
>Stephen

I can't really vote on this because I definitely disagree with the reason 
you are putting forth for advocating the display() method.

Also it really skews the vote to throw out a whole new idea of why it 
should be called display and then ask people to vote on what it should be 
called without asking first for comments so that all the pros and cons can 
be listed more objectively. In addition, psychologically just putting 
display as the first choice will entice people to choose display().

:)

The reason I disagree is that I do not believe that widgets should know 
about generating hidden vars vs the rendered value. It's the same arguement 
for widgets not knowing how to generate readonly vs editable widgets that I 
brought up earlier.

It's fairly clear in my mind that widgets should render themselves and that 
they should only have one render() method. None of this 
display_hidden_state() display_editable() display_readonly type of methods. 
That's way too much for the widget API, IMHO.

I do think that displaying hidden state values is useful. However, I think 
it should be part of an API that allows a widget to generate values based 
on the values of other widgets. And I believe that state maintenance is so 
application specific, that there should be a widget devoted to 
demonstrating this.

In our Java widget API, we call the state the user is in the "User Gesture" 
and hence all actions and views get access to the user gesture object which 
also coincidentally knows what parameters are vital to keep around in order 
to maintain state. I think it would be appropriate for an HTMLContainer of 
widgets to know how to generate a state maintenance widget based on a config.

Gesture is a pattern that I believe the Java J2EE whitepapers endorse as 
the mechanism for passing data in a model-view-controller architecture.

[Perl-widget-developer] Freezing and Thawing widgets was: Teambuilding...

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

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/

Re: [Perl-widget-developer] Dynamically configured Widgets

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

At 09:35 AM 6/7/2001 +1000, Cees Hek wrote:
>On Tue, 5 Jun 2001, Stephen Adkins wrote:
>
> > I originally thought that every attribute should be required to be
> > configured from the config file.
> > Now I think that every configurable attribute should be *able* to be
> > configured from the config file, but that it should also be *able* to
> > be overridden by the constructor parameters.
>
>Excellent.  That's exactly how I see it.
>
> > I actually would like to create data-bound controls as well,
> > where the SQL to populate the controls can be configured into the
> > config file and the values are populated at run time.
>
>I really like the sounds of that

Yup, although I don't want it lose that that I believe this logic belongs 
in a container for the widgets with an API to change the widget values as 
stated previously using the GPC paradigm of PHP. But adding session, 
database(s), and other data sources as necessary.

ie DB Logic itself probably should not go into the widgets themselves. And 
furthermore, by providing the appropriate mutator methods in the widgets 
and the DBAwareness in a container, then all widgets will be DBAware.

Later,
    Gunther

Re: [Perl-widget-developer] Structure of Widget Base classes

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

At 01:42 PM 6/7/2001 -0400, Stephen Adkins wrote:
>At 12:26 AM 6/7/2001 +0200, Issac Goldstand wrote:
>...
> >> What if we used the following structure:
> >>
> >> Widget::Base - base class for all widgets
> >> Widget::Select - a generic dropdown box widget (inherits from
> >Widget::Base)
> >>
> >> Widget::HTML::Base - a base class for HTML widgets (doesn't inherit)
> >> Widget::HTML::Select - a display class for Select box
> >> (inherits from Widget::HTML::Base)
> >>
> >> The Widget::Select object can instantiate the correct display object from
> >> one of the interfaces once it knows (from the config file) which interface
> >> we are displaying to. It can choose to use Widget::HTML::Select or
> >> Widget::WML::Select depending on the requirements.
> >>
> >>
> >> Does anyone have any other ideas or comments on the implications of this?
> >> I haven't thought this out completely yet, but I wanted to throw it out
> >> before we got too deep into the coding.
> >
> >This is pretty much what I've been ranting about for the past week or so - I
> >belive that we should have something like:
> >
> >Widget::Object (base class)
> >Widget::Object::Select (pseudo-code for select - contains 'template'
> >instructions for rendering code and any other internals needed)
>
>I weighed in with my opinion earlier.
>
>Recommendation:
>    Keep classes in Widget::*::Button package structure rather than
>Widget::Button::*.
>Reasons:
>    1. The Widget::* classes share much more in common than Widget::Button
>classes
>    2. I think every user interface technology will have *different* widgets
>    3. I want to be able to delegate packages like Widget::Curses and
>Widget::Gtk
>       to individuals who have expertise in those skills
>    4. Common code can be put in Widget::Base::Button class and inherited
>Remedy:
>    If you don't like this, let's not argue about it any further until we have
>    actual widget code which demonstrates the benefits of one over the other.
>    Develop a widget on the current code base.
>    Then reorganize the code base and implement the widget there.
>    If you find *compelling* advantages, share your code bases with the list.
>
> >Widget::Renderer (base class for renderer [is this needed?  I'm not quite
> >sure yet])
> >Widget::Renderer::HTML (class to render pseudo-code to HTML/JavaScript)
> >Widget::Renderer::WML (class to render pseud-code to WML/WMLScript [or
> >whatever OpenWave's calling their scripting language])
>
>This addresses my "logical widget" vs. "physical widget" discussion from
>earlier.
>I believe that basically, there are *no* logical widgets, such that we need a
>driver or "renderer" class in order to make them physical.  Every widget knows
>exactly how to render itself.
>
>It is the Controller which makes the choice about which physical widget
>should
>be returned.
>
>Stephen

I agree with this. And I also said it in a different way in my previous 
mail. I am just now going through a weeks worth of widget mails and I 
didn't see this follow up until now. Sorry...

Re: [Perl-widget-developer] Structure of Widget Base classes

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

At 10:03 AM 6/7/2001 +1000, Cees Hek wrote:
>On Tue, 5 Jun 2001, Stephen Adkins wrote:
>
> > Several people have commented on this topic.
> >
> > Is it 1. Widget::HTML::Select ?
> > ....or 2. Widget::Select::HTML ?
> >
> > I believe that "all of the HTML widgets" have more in common
> > than "all of the Select widgets".  That's why I chose #1 rather
> > than #2.
>
>I don't think you can easily make that generalization about all widgets.
>I agree with you that for simple widgets, most of the package will be
>about how to render the widget.  But when you look at a widget like the
>Databound Select widget you mentioned in an other email, then I can see a
>lot of code that can be shared between all those databound select widgets.
>And if we look back at the DateDropDowns widget, It doesn't need to know
>anything at all about how to render itself, since it uses three
>sub-widgets to do all the rendering work.  All DateDropDowns really does
>is figure out how the user wants the sub-widgets configured, and handles
>splitting and joining the date values (in other words all of it could be
>shared across the HTML, WML or Gtk interfaces).
>
>However, I can also see your point about keeping the HTML stuff together
>and the Gtk stuff together.  So I would be happy using the multiple
>inheritance model, where Widget::HTML::DateDropDowns would inherit from
>Widget::HTML::Base and Widget::Base::DateDropDowns.

Well, the problem here as with many design/architecture problems is that 
there are many ways people may want to use something so you can't please 
everyone.

In these cases, the appropriate architecture pattern is to chose one of two 
things

1) Either the simplest way of ordering the widgets

or

2) Ordering according to how the widgets will be used most commonly.

In this case, we have, I believe (even if some of you do not), a clear cut 
winner. Order by render type eg

HTML::TextField
WML::TextField etc..

This is how most people will deal with widgets (most will just use HTML) 
and it is the simplest because it ties the structure to a very concrete 
concept of rendering. Data and Browser awareness and the rest of the funky 
ideas are very abstract concepts and difficult to order by properly.

Furthermore, I would also argue that in the end you will likely find that 
the right design pattern for data awareness is that widgets have standard 
accessors/mutators where the data awareness comes from the container 
choosing to map data to the widgets.

I hope this explains/resolves the whole structure issue. Of course, it 
probably won't. But I do strongly feel that the structure I describe above 
is the most appropriate to please the most people and still accommodate 
flexibility.

Re: [Perl-widget-developer] Structure of Widget Base classes

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

At 12:26 AM 6/7/2001 +0200, Issac Goldstand wrote:
> >
> > I have a concern with the current structure of the base
> > classes.  Currently the way I see it, the structure is as follows
> >
> > Widget::Base - base class for all widgets
> > Widget::HTML::Base - base class for all HTML widgets (inherits
>Widget::Base)
> > Widget::HTML::Select - a widget class (inherits from Widget::HTML::Base)
> >
> > Now if we add WML we would get the following extra classes
> >
> > Widget::WML::Base - base class for all HTML widgets (inherits
>Widget::Base)
> > Widget::WML::Select - a widget class (inherits from Widget::HTML::Base)
> >
> >
> > My concern here is that there is no sharing of code between
> > Widget::HTML::Select and Widget::WML::Select besides the Widget::Base and
> > Widget::HTML::Base.  I think there should be a base class for Select
> > widgets that the HTML and WML Select widgets can inherit from.  Otherwise
> > we will be duplicating a tonne of code between the different interfaces.
> >
> >
> > Essentially, I think we have our Base class structure backwards.  What we
> > need to think about is what similarities and differences there will be
> > between the different interfaces.  The only method that should be
> > different in a Widget is the method that renders the actual widget.
> > Everything else will most likely be the same.
> >
> > To fit a Widget::Select baseclass into the current structure would require
> > multiple inheritance, and I don't know if that is such a good idea.
> >
> >
> > What if we used the following structure:
> >
> > Widget::Base - base class for all widgets
> > Widget::Select - a generic dropdown box widget (inherits from
>Widget::Base)
> >
> > Widget::HTML::Base - a base class for HTML widgets (doesn't inherit)
> > Widget::HTML::Select - a display class for Select box
> > (inherits from Widget::HTML::Base)
> >
> > The Widget::Select object can instantiate the correct display object from
> > one of the interfaces once it knows (from the config file) which interface
> > we are displaying to. It can choose to use Widget::HTML::Select or
> > Widget::WML::Select depending on the requirements.
> >
> >
> > Does anyone have any other ideas or comments on the implications of this?
> > I haven't thought this out completely yet, but I wanted to throw it out
> > before we got too deep into the coding.
>
>This is pretty much what I've been ranting about for the past week or so - I
>belive that we should have something like:
>
>Widget::Object (base class)
>Widget::Object::Select (pseudo-code for select - contains 'template'
>instructions for rendering code and any other internals needed)
>
>Widget::Renderer (base class for renderer [is this needed?  I'm not quite
>sure yet])
>Widget::Renderer::HTML (class to render pseudo-code to HTML/JavaScript)
>Widget::Renderer::WML (class to render pseud-code to WML/WMLScript [or
>whatever OpenWave's calling their scripting language])
>
>The programer should select a Renderer object by tying it into the
>controller when constructing
>(eg. my $wc=new Widget(-options.... -renderer=>"Widget::Renderer::HTML");  )
>
>   Issac

I quite like this distinction between widget helper classes (in object) and 
the ones that are meant to be directly renderable.

Re: [Perl-widget-developer] Properties - object variables vs. accessors

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

I think that I prefer the 2nd strategy first. It is possible that it is 
necessary to go back and recode to support inheritence. However, there is 
something that has been overlooked here.

Inheritence is probably not the way most people will deal with widgets. I 
would posit based on my prior experience is most cases of widget reuse 
involves a has-a rather than is-a relationship -- a containment issue.

So if I write a DateTime widget, it would have a date widget and a time 
widget but usually not inheriting from Date widget and then adding Time 
functionality.

Of course, there are cases where inheritence is useful. I am not saying 
they don't exist. But in my experience with writing widgets for JSPs, I 
have almost never had to resort to inheritance.

At 12:25 PM 6/5/2001 -0700, ja...@la... wrote:
>Great - and you are absolutely right about the two camps for 
>implementation. In my work I took the 2nd strategy initially and ended up 
>going back and redoing that code to use accessor methods anyway.
>
>By using accessors at all times you are going to allow people like me to 
>override data type declarations with what I want but support Gunther's 
>wish for total simplicity of implementation.
>
>I do accept that there is a performance tradeoff.* Perhaps, before getting 
>too excited about performan implications we might choose to benchmark 
>this. How you implement it will affect the performance. (ie/ using 
>AUTOLOAD could be done slow - but creating closures can make it fast.) 
>Also - by itemizing the list of possible keys upfront can you not open to 
>the possiblity of a pseudohash which is faster and more compact that 
>standard hashes?
>
>Jay
>
>* I remember Stephen's statement of flexibility over performance!
>
>On Tue, 05 June 2001, Stephen Adkins wrote:
>
> >
> > Hi,
> >
> > Yes, we absolutely need accessors.
> > I recommend an AUTOLOAD method implemented on Widget::Base to
> > create accessors automatically (for now, anyway).
> >
> > However, there are two schools of thought on use of accessors vs.
> > accessing the attributes directly.
> >
> >  1. use accessors everywhere, even inside the class
> >  2. use accessors outside the class, access the attribute directly
> >     from within the class
> >
> > I prefer #2 for performance.
> > Some people argue #1 so that subclasses are resilient to change in the
> > superclass.  I think we just don't have a complex enough code base to
> > make #1 critical.  It won't be look before we finalize how to access
> > attributes internally.  Then it should be stable.
> >
> > Stephen
> >
> > At 10:22 AM 6/5/2001 -0400, Jay Lawrence wrote:
> > >Hey all,
> > >
> > >I was looking at the code and noticed one thing that will severely 
> limit our
> > >implementation flexibility. It has to do with how properties are 
> accessed in
> > >a non-abstracted fashion.
> > >
> > >When an widget is created (Widget::Base::new) you pass your properties 
> which
> > >then get stuffed in the object hash for later use.
> > >
> > >OK - so you're storing properties like $widget->{'name'} = "button1". (Oh,
> > >BTW, shouldn't you enclose hash keys in quotes? I know it generally works
> > >but it generates warnings).
> > >
> > >And you're obtaining it same way ie:
> > >    print "My name is ".$self->{'name'};
> > >
> > >However, if you choose to have a different storage mechanism OR want 
> to get
> > >fancy with how properties are resolved you need to use accessor 
> methods. ie/
> > >    print "My name is ".$self->name;
> > >
> > >This way you hide the implementation of the widget (abstraction) from the
> > >calling routine. You actually need to use this strategy everywhere.
> > >
> > >There are a number of ways to handle this:
> > >    AUTOLOAD - resolve name of method to a property or raise error
> > >    manual accessor contruction - lots 'n lots of subs
> > >    automated accessor construction - 1/2 doz packages in CPAN that do the
> > >job
> > >
> > >I know there will be arguments of efficiency vs. flexibility but I do 
> recall
> > >Stephen saying that at this stage we'll be thinking more on 
> flexibility than
> > >efficiency. But down the road we might be able to trade the expense of a
> > >function call with a more efficient storage mechanism like pseudohashs.
> > >
> > >Jay
> > >
> > >
> > >
> > >_______________________________________________
> > >Perl-widget-developer mailing list
> > >Per...@li...
> > >http://lists.sourceforge.net/lists/listinfo/perl-widget-developer
> > >
>
>
>
>_______________________________________________
>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/

Re: [Perl-widget-developer] Widget.pm design

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

At 11:19 AM 6/5/2001 -0500, James G Smith wrote:
>Gunther Birznieks <gu...@ex...> wrote:
> >I disagree in general with this. Having coded a lot of WML and HTML myself
> >for a local mobile company, I can say pretty strongly that I do not believe
> >in a 1-1 mapping between elements in WML and HTML except in a very loose
>sense.
> >
> >You really have to code the whole template very separately for WML vs HTML
> >and the choice you make (eg textfield vs textarea) is very different on WML
> >vs HTML.
> >
> >So you would not want some generic Widget::TextField that rents a WML
> >version for WML and HTML for HTML. It's quite possible that on web you may
> >want to allow the user to type in a lot of info in textarea but on wap, you
> >just restrict it a bit more.
>
>Then perhaps the widgets are being too closely tied to the end result.  The
>Widget::TextField should know which way is best for the environment in which
>it is being rendered.  Why force the coder to figure out the best way to put
>up a text input field?  That complicates the higher-level coding and we have
>lost the abstractions we are trying to put in place -- the developer has
>gained nothing from using the Widget set except having to learn yet another
>way to do things.

I think the statement here "gained nothing" is really a bit harsh. There 
are many other features of widgets that are quite useful as indicated here 
before. If you think that they have gained 'nothing' after the previous 
conversation then I am not sure what to say.

>The Widget::Thingy class will know which of it's classes to use for 
>rendering.
>  For HTML, it might use Widget::Thingy::HTML while in WAP it uses
>Widget::Thingy::WAP.  The Widget::Thingy class itself contains the logic used
>to tie itself together, not actually render itself.  If it has to worry about
>which way to render a constituant widget, then it's not using a sufficiently
>abstract widget.
>
>Hopefully widgets will be more abstract than just Perl wrappers around the
>HTML set of input objects.

Well, I don't think this was my stand. This is a bit overstating a simple 
argument. Really it is the difference between a widget that is a text field 
knowing what to output for HTML vs WML and a widget that is a WML textfield 
vs a widget that is an HTML text field.

I prefer the second form. Each widget should encapsulate the minimum atomic 
operation. Note, that with a composite pattern you can simply wrap other 
widgets if you want to in order to do more more complex logical feats, but 
overloading the widget library to have to include hooks to understand when 
it should output HTML vs WML vs something else feels quite cumbersome to me.

Not to mention that in real world practicle that WML screens are often 
designed extremely differently from HTML screens. You really can't just 
replace the widget 1-1. In most cases the entire presentation has to change 
by nature.

Also, I can think of yet another more useful difference which would not be 
covered by introspecting the browser type -- that of displaying 
display-only widgets and editable widgets. This is something theoretically 
really useful because many applications require support for this -- even if 
they are just HTML.

Consider a WebDB. A WebDB has a search screen which will produce a set of 
tabular results from the search. These results will usually be plain text 
representations of the column values for all the displayed records. But if 
you click on a modify button, the next screen that is generated should 
place the editable form of column widgets on the screen.

So you would have

$widget->displayReadOnlyForm();

$widget->displayEditableForm();

Yet, I would still ague, even with the demonstrative usefulness of this 
addition to the API, to please not include it in the core atomic widget API.

I think we can all come up with many different ways of doing this part of 
the API and therefore it should not be included in the core atomic widget.

Rather, I think it is better off handled with wrappers (composites) that 
suit the logic that the app developer may want. And in many cases this 
should be handled by a container being configured for particular 
screens.  Usually when there are many ways to arrange something (like 
widgets) the appropriate design pattern is to leave it to external 
containers to deal with the decision making process. Otherwise you are 
tying it too much to your own way of making applications which isn't 
necessarily how others write applications.

Re: [Perl-widget-developer] VOTE: display() name

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

> ISSUE #1:
>
>
>    1. display()
>    2. render()
>    3. show()
>    4. draw()

1.  display()

> ISSUE #2 (related):
>
> On HTML widgets, I think there is still a place for an html()
> method.  This method has no parallels in the Gtk or Curses
> widgets.  However, the difference is that calling the html()
> method on an HTML widget simply requests the widget to report
> the HTML that would be used.  Calling the display() method
> (or render() or whatever) is a tacit promise that the HTML
> will be displayed.
>
> This information will be of use in handling the state management.
> Variables in the State which have not been "display()ed" can
> be maintained by creating <input type=hidden> elements.
>
> It is because of this difference between the html() method
> and the display() method that "display()" seems better to me
> than "render()".
>
Against. I still think a display "driver" should be loaded by the Controller
and used to display() any Widgets requested.  That seems to me the most
compatible with any type of Widget that we'll ever want to create, and
therefore means less overhead to expand the library later.

  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

[Perl-widget-developer] XSP PerForm taglib (fwd)

[Matt S. <ma...@se...>]

Thought this might interest some of you widget geeks :-)

-- 
<Matt/>

    /||    ** Founder and CTO  **  **   http://axkit.com/     **
   //||    **  AxKit.com Ltd   **  ** XML Application Serving **
  // ||    ** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** mod_perl news and resources: http://take23.org  **
     \\//
     //\\
    //  \\

---------- Forwarded message ----------
Date: Fri, 8 Jun 2001 22:40:56 +0100 (BST)
From: Matt Sergeant <ma...@se...>
To: AxKit Users Mailing List <axk...@ax...>
Subject: XSP PerForm taglib

Taking a bunch of ideas from a number of places I've started putting
together what I call the "PerForm" taglib. This is sort of a magic form
tag library that will enable you to write web forms sucking data from
various sources more easily.

I'm looking for some sort of feedback on this, though it's pretty funky as
it stands IMHO.

Best way to describe it is with an example (this assumes passing
familiarity with XSP):

===============

<?xml version="1.0"?>
<xsp:page
    xmlns:xsp="http://apache.org/xsp/core/v1"
    xmlns:web="http://axkit.org/NS/xsp/webutils/v1"
    xmlns:f="http://axkit.org/NS/xsp/perform/v1"
    language="perl"
    indent-result="yes"
>
<!-- TOP LEVEL LOGIC -->
<xsp:logic>

# Each function recieves a $ctxt object, which is a hash to
# store things in. It has one entry by default, "Form", which
# is a hash of form values

sub load_title {
    my ($ctxt, $default, $current) = @_;
    warn("load_title ($default, $current)\n");
    return $current || $default;
}

sub load_link {
    my ($ctxt, $default, $current) = @_;
    warn("load_link ($default, $current)\n");
    return $current || $default;
}

sub save_title {
    my ($ctxt, $new_value) = @_;
    warn("save_title : $new_value\n");
}

sub save_link {
    my ($ctxt, $new_value) = @_;
    warn("save_link : $new_value\n");
}

sub start_form_create {
    my ($ctxt, $save_mode) = @_;
    warn("start_form\n");
}

sub end_form_create {
    my ($ctxt, $save_mode) = @_;
    warn("end_form\n");
    # if everything is OK, and we're in save_mode, redirect.
    if ($save_mode) {
       if ($ctxt->{OK}) {
         # note mixing taglibs and Perl!!!
         <web:redirect uri="everything_ok.xsp"/>
       }
    }
}

</xsp:logic>

<html>

<head>
<title>Blah blah</title>
</head>

<body>

<f:form name="create">

Title: <f:textfield type="text" name="title" width="30"
maxlength="255" />
<br />
Link: <f:textfield type="text" name="link" width="30"
maxlength="255" />
<br />

<!-- I haven't coded the submit button yet! -->
<input type="submit"/>

</f:form>

</body>
</html>
</xsp:page>

===============

OK, hopefully that hasn't confused anyone too much. Now the idea is that
these forms always get submitted back to themselves. They do their own
validation. If everything went well and the form got saved OK, they issue
a redirect to another page. It's kinda like the MVC model, only slightly
spiced the AxKit way :-)

Now when the form is first loaded, the input fields are populated by a
callback to the load_<name>() function, where <name> is the name entry of
the particular form field. So to populate the first textfield, it calls
load_title(...). It passes in parameters $ctxt, $default, and $current.
Note that $current will only be filled if this form has already been
submitted once (filled with the current value, obviously). The value you
return is what goes in the text box that the user sees.

When the form is submitted, the save_<name>() functions are called. This
time they are passed the $ctxt and the new value. There you can do
validation or whatever you like (save to a DB, etc).

Each view of the form is started by a call to start_form_<name>(), where
<name> this time is the name attribute on the form. When all the form's
callbacks have been performed, the end_form_<name>() callback is called.

The $ctxt object is a simple hashref that you can fill with whatever you
like. It's there to help you maintain state between the callbacks. It
contains one entry by default, "Form", which is a hashref to all the other
form values. This allows you to do validation where one value depends on
another.

If you *don't* want to supply callbacks for load_*, then it defaults to
using either the current value (i.e. the value last posted to the form),
or the default value specified if this is the first load of this form.

Now when all this has been done, it doesn't generate a HTML widget. It
just generates some XML decorated with all the relevant attributes. You
need to write an XSLT stylesheet (which I'll include with the package for
HTML) to render it to HTML. But it's really simple to do that with
xsl:include/xsl:import. I may even be persuaded to do an XPathScript
stylesheet for it :-)

I welcome your feedback on this. I think it will make building complex
forms really easy. One nice thing with XML is we can put all that nasty
callbacks code in another file, and use entities to load it in. Or we can
use "use OtherPackage qw(...)" to import the functions to the current
namespace. Either way will work.

I can put this in CVS if people want to play with it as it stands. But I
have only implemented the textfield widget as yet.

-- 
<Matt/>

    /||    ** Founder and CTO  **  **   http://axkit.com/     **
   //||    **  AxKit.com Ltd   **  ** XML Application Serving **
  // ||    ** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** mod_perl news and resources: http://take23.org  **
     \\//
     //\\
    //  \\


---------------------------------------------------------------------
To unsubscribe, e-mail: axk...@ax...
For additional commands, e-mail: axk...@ax...

Re: [Perl-widget-developer] Widget and templates - QED - stringify overloading

[<ja...@la...>]

On the subject of overloading - not overlording....

I made a sample where I have:

 Widget_Test ISA Widget_SuperTest ISA Widget_Base

The overload syntax that I showed below would go into Widget_Base

Try 1 - Widget_Base.pm has:
  use overload '""' => &display;

  This has the unfortunate consequence of binding to the Widget_Base::display method right off the bat. No good for subclasses.

Try 2 - Widget_Base.pm has:
  use overload '""' => "display";

  This allows for the object instance class to provide the method  and will follow ISA if not defined in calling class.

MAJOR BONUS FOR ALL
The performance difference between:
  print $widget->display [direct]
and 
  print $widget [overload]
is a whopping 30-35 times on my machine.

direct: 42 wallclock secs (42.48 usr +  0.00 sys = 42.48 CPU) @ 11770.24/s (n=500000)
overload:  1 wallclock secs ( 1.35 usr +  0.00 sys =  1.35 CPU) @ 370370.37/s (n=500000)

Wow, eh!

Jay

On Fri, 08 June 2001, Stephen Adkins wrote:

> 
> At 10:10 AM 6/8/2001 -0700, ja...@la... wrote:
> >There were a couple of good points about my proposed how to use widgets in
> Templating systems. I know the thought of changing a system like Template
> Toolkit is unattractive. In the long run I feel a few strategic changes
> could make all lives easier.
> >
> >HOWEVER - GET THIS:
> >
> >I thought to myself if we do something like:
> >  $widget=[ a widget instance ];
> >  print $widget;
> >
> >We get a lovely output like:
> >  Widget::HTML::Thinggy=HASH(0x80903040)
> >
> >Using the overload (perldoc overload) package we can simply overload the
> stringify operator to whatever we wish:
> >
> >Pacakge Widget::HTML::Thinggy;
> >
> >sub render_html {
> >}
> >
> >use overload '""' => \&render_html; # or *whatever*
> 
> Good idea.
> 
> >Now print $widget will actually call render_html to create what to print.
> Delicious.
> >
> >I can rip out the funky code I whacked into Template Toolkit and still
> just place my widget where I want, calling it by name and seeing its
> default rendering (HTML) in all its glory.
> >
> >We should look at putting this into the Widget::HTML::Base.pm package.
> >
> 
> Good idea.
> 
> >use overload '""' => \&render; # Does this inherit properly? Maybe not.
> Might need a bit of fancy footwork for subclasses to Widget::HTML::Base
> 
> Give this a try and let us know what works.
> 
> Stephen

Re: [Perl-widget-developer] VOTE: display() name

[<ja...@la...>]

> My ordered votes for what to call it are:
> 
>    1. display()
>    2. render()
>    3. show()
>    4. draw()

1st choice is display
2nd choice is show

Jay

[Perl-widget-developer] VOTE: display() name

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

Hi,

ISSUE #1:

I am requesting a quick vote to put to bed this naming issue.
I agree that we need a 

   $widget->display()

method.
My ordered votes for what to call it are:

   1. display()
   2. render()
   3. show()
   4. draw()

ISSUE #2 (related):

On HTML widgets, I think there is still a place for an html()
method.  This method has no parallels in the Gtk or Curses
widgets.  However, the difference is that calling the html()
method on an HTML widget simply requests the widget to report
the HTML that would be used.  Calling the display() method
(or render() or whatever) is a tacit promise that the HTML
will be displayed.

This information will be of use in handling the state management.
Variables in the State which have not been "display()ed" can
be maintained by creating <input type=hidden> elements.

It is because of this difference between the html() method
and the display() method that "display()" seems better to me
than "render()".

Please vote... or *forever* hold your peace.

Stephen

Re: [Perl-widget-developer] Widget and templates - QED - stringify overloading

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

At 10:10 AM 6/8/2001 -0700, ja...@la... wrote:
>There were a couple of good points about my proposed how to use widgets in
Templating systems. I know the thought of changing a system like Template
Toolkit is unattractive. In the long run I feel a few strategic changes
could make all lives easier.
>
>HOWEVER - GET THIS:
>
>I thought to myself if we do something like:
>  $widget=[ a widget instance ];
>  print $widget;
>
>We get a lovely output like:
>  Widget::HTML::Thinggy=HASH(0x80903040)
>
>Using the overload (perldoc overload) package we can simply overload the
stringify operator to whatever we wish:
>
>Pacakge Widget::HTML::Thinggy;
>
>sub render_html {
>}
>
>use overload '""' => \&render_html; # or *whatever*

Good idea.

>Now print $widget will actually call render_html to create what to print.
Delicious.
>
>I can rip out the funky code I whacked into Template Toolkit and still
just place my widget where I want, calling it by name and seeing its
default rendering (HTML) in all its glory.
>
>We should look at putting this into the Widget::HTML::Base.pm package.
>

Good idea.

>use overload '""' => \&render; # Does this inherit properly? Maybe not.
Might need a bit of fancy footwork for subclasses to Widget::HTML::Base

Give this a try and let us know what works.

Stephen

[Perl-widget-developer] Widget and templates - QED - stringify overloading

[<ja...@la...>]

There were a couple of good points about my proposed how to use widgets in Templating systems. I know the thought of changing a system like Template Toolkit is unattractive. In the long run I feel a few strategic changes could make all lives easier.

HOWEVER - GET THIS:

I thought to myself if we do something like:
  $widget=[ a widget instance ];
  print $widget;

We get a lovely output like:
  Widget::HTML::Thinggy=HASH(0x80903040)

Using the overload (perldoc overload) package we can simply overload the stringify operator to whatever we wish:

Pacakge Widget::HTML::Thinggy;

sub render_html {
}

use overload '""' => \&render_html; # or *whatever*



Now print $widget will actually call render_html to create what to print. Delicious.

I can rip out the funky code I whacked into Template Toolkit and still just place my widget where I want, calling it by name and seeing its default rendering (HTML) in all its glory.

We should look at putting this into the Widget::HTML::Base.pm package.

I see that right we're waffling with what to call - render, print, display, whatever...

package Widget::HTML::Base;

# Default rendering - shows the bad news
sub render {
 my $self=shift;
 return "no html rendering for this widget.";
}

use overload '""' => \&render; # Does this inherit properly? Maybe not. Might need a bit of fancy footwork for subclasses to Widget::HTML::Base

1;

Re: [Perl-widget-developer] Widget.pm design

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

At 12:50 AM 6/7/2001 +0200, Issac Goldstand wrote:
...
>> So you would not want some generic Widget::TextField that rents a WML
>> version for WML and HTML for HTML. It's quite possible that on web you may
>> want to allow the user to type in a lot of info in textarea but on wap,
>you
>> just restrict it a bit more.
>
>Still, it's going to be called the same thing (TextField), so why make it
>_look_ complicated, too?
>
>The fact of the matter is, that the widgets are going to exist (as much as
>possible) across the board (of rendering environments, that is).

I don't think so.
We won't have a Widget::WML::TreeView.
Between Widget::HTML::Button and Widget::Gtk::Button, I predict there will
be very little code in common.

Again.  Let's not theorize too much about what might be.
Let's go ahead and develop some widgets.
Then we can discuss the merits of differing views based on real widgets.

...

>IMHO, I think that the Widget::Renderer base class should contain work as
>follows:
>
>it should contain a list of template commands - the list should be seperated
>into two sets:
>
>REQUIRED commands.  These are the most basic of basics - basic text input,
>basic label, etc
>this list should be as minimal as we can - each Renderer child MUST
>implement these properly.
>
>RECOMMENDED commands - These are more advanced things like buttons.  They,
>too, must be implemented across all inherited objects - BUT, not necessarily
>as the requested object - they could generate an error of some sort (either
>via perl, or via the actual output) that warns that there was no way of
>implementing them (eg - they just have to be there and do SOMETHING - they
>don't have to do what it was expected).
>

You raise good points about questioning the extent to which we can make
several widgets interchangeable and proposing how we can do this.
Let's continue to think about this as we develop widgets.

>
>  Issac
>

Stephen

Re: [Perl-widget-developer] Structure of Widget Base classes

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

At 12:26 AM 6/7/2001 +0200, Issac Goldstand wrote:
...
>> What if we used the following structure:
>>
>> Widget::Base - base class for all widgets
>> Widget::Select - a generic dropdown box widget (inherits from
>Widget::Base)
>>
>> Widget::HTML::Base - a base class for HTML widgets (doesn't inherit)
>> Widget::HTML::Select - a display class for Select box
>> (inherits from Widget::HTML::Base)
>>
>> The Widget::Select object can instantiate the correct display object from
>> one of the interfaces once it knows (from the config file) which interface
>> we are displaying to. It can choose to use Widget::HTML::Select or
>> Widget::WML::Select depending on the requirements.
>>
>>
>> Does anyone have any other ideas or comments on the implications of this?
>> I haven't thought this out completely yet, but I wanted to throw it out
>> before we got too deep into the coding.
>
>This is pretty much what I've been ranting about for the past week or so - I
>belive that we should have something like:
>
>Widget::Object (base class)
>Widget::Object::Select (pseudo-code for select - contains 'template'
>instructions for rendering code and any other internals needed)

I weighed in with my opinion earlier.

Recommendation: 
   Keep classes in Widget::*::Button package structure rather than
Widget::Button::*.
Reasons:
   1. The Widget::* classes share much more in common than Widget::Button
classes
   2. I think every user interface technology will have *different* widgets
   3. I want to be able to delegate packages like Widget::Curses and
Widget::Gtk
      to individuals who have expertise in those skills
   4. Common code can be put in Widget::Base::Button class and inherited
Remedy:
   If you don't like this, let's not argue about it any further until we have
   actual widget code which demonstrates the benefits of one over the other.
   Develop a widget on the current code base.
   Then reorganize the code base and implement the widget there.
   If you find *compelling* advantages, share your code bases with the list.

>Widget::Renderer (base class for renderer [is this needed?  I'm not quite
>sure yet])
>Widget::Renderer::HTML (class to render pseudo-code to HTML/JavaScript)
>Widget::Renderer::WML (class to render pseud-code to WML/WMLScript [or
>whatever OpenWave's calling their scripting language])

This addresses my "logical widget" vs. "physical widget" discussion from
earlier.
I believe that basically, there are *no* logical widgets, such that we need a 
driver or "renderer" class in order to make them physical.  Every widget knows
exactly how to render itself.

It is the Controller which makes the choice about which physical widget
should 
be returned.

Stephen

>The programer should select a Renderer object by tying it into the
>controller when constructing
>(eg. my $wc=new Widget(-options.... -renderer=>"Widget::Renderer::HTML");  )
>
>  Issac
>

Re: [Perl-widget-developer] Teambuilding Exercise #2: Usage - Template Toolkit concept

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

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...

Re: [Perl-widget-developer] Widget.pm design

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

> I disagree in general with this. Having coded a lot of WML and HTML myself
> for a local mobile company, I can say pretty strongly that I do not
believe
> in a 1-1 mapping between elements in WML and HTML except in a very loose
sense.
>
> You really have to code the whole template very separately for WML vs HTML
> and the choice you make (eg textfield vs textarea) is very different on
WML
> vs HTML.
>
> So you would not want some generic Widget::TextField that rents a WML
> version for WML and HTML for HTML. It's quite possible that on web you may
> want to allow the user to type in a lot of info in textarea but on wap,
you
> just restrict it a bit more.

Still, it's going to be called the same thing (TextField), so why make it
_look_ complicated, too?

The fact of the matter is, that the widgets are going to exist (as much as
possible) across the board (of rendering environments, that is).  Therefore,
it's silly to make the developers' lives hard by having them have to start
picking different classes for HTML, WML, Curses, etc.  It also makes Widget
developers' lives hard - if we could come up with some templating language
that _WE_ could port across the different rendering environments, then not
only could the Widget::Base inheriting class developer not have to worry
about porting their widgets across environments, but Widget::Renderer
inheriting class developers could easily add Renderers for ALL widgets.

IMHO, I think that the Widget::Renderer base class should contain work as
follows:

it should contain a list of template commands - the list should be seperated
into two sets:

REQUIRED commands.  These are the most basic of basics - basic text input,
basic label, etc
this list should be as minimal as we can - each Renderer child MUST
implement these properly.

RECOMMENDED commands - These are more advanced things like buttons.  They,
too, must be implemented across all inherited objects - BUT, not necessarily
as the requested object - they could generate an error of some sort (either
via perl, or via the actual output) that warns that there was no way of
implementing them (eg - they just have to be there and do SOMETHING - they
don't have to do what it was expected).

each inherited renderer must contain implementation for the whole list of
commands and no more.  renderer developers should be discouraged from
writing an 'enhanced' language for his/her renderer - this will only cause
incompatibility probelms.  As long as we're on sourceforge, I'd say that if
someone thinks we're missing a template command, it should be brought to the
mailing list for a suitable period of time (2 weeks?) for consideration.  If
accepted, we'll update the base renderer object, and patch all inherited
objects to include it.  As long as it's a "recommended" command, this is
easy - we just patch it to display a warning, until the original developer
gets a chance to patch it better...

Sorry if I may have bended the "two topics in one post" rule a b it here,
but the two were very closely related so I felt it neessary to express it in
one post...

  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

Re: [Perl-widget-developer] Structure of Widget Base classes

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

>
> I have a concern with the current structure of the base
> classes.  Currently the way I see it, the structure is as follows
>
> Widget::Base - base class for all widgets
> Widget::HTML::Base - base class for all HTML widgets (inherits
Widget::Base)
> Widget::HTML::Select - a widget class (inherits from Widget::HTML::Base)
>
> Now if we add WML we would get the following extra classes
>
> Widget::WML::Base - base class for all HTML widgets (inherits
Widget::Base)
> Widget::WML::Select - a widget class (inherits from Widget::HTML::Base)
>
>
> My concern here is that there is no sharing of code between
> Widget::HTML::Select and Widget::WML::Select besides the Widget::Base and
> Widget::HTML::Base.  I think there should be a base class for Select
> widgets that the HTML and WML Select widgets can inherit from.  Otherwise
> we will be duplicating a tonne of code between the different interfaces.
>
>
> Essentially, I think we have our Base class structure backwards.  What we
> need to think about is what similarities and differences there will be
> between the different interfaces.  The only method that should be
> different in a Widget is the method that renders the actual widget.
> Everything else will most likely be the same.
>
> To fit a Widget::Select baseclass into the current structure would require
> multiple inheritance, and I don't know if that is such a good idea.
>
>
> What if we used the following structure:
>
> Widget::Base - base class for all widgets
> Widget::Select - a generic dropdown box widget (inherits from
Widget::Base)
>
> Widget::HTML::Base - a base class for HTML widgets (doesn't inherit)
> Widget::HTML::Select - a display class for Select box
> (inherits from Widget::HTML::Base)
>
> The Widget::Select object can instantiate the correct display object from
> one of the interfaces once it knows (from the config file) which interface
> we are displaying to. It can choose to use Widget::HTML::Select or
> Widget::WML::Select depending on the requirements.
>
>
> Does anyone have any other ideas or comments on the implications of this?
> I haven't thought this out completely yet, but I wanted to throw it out
> before we got too deep into the coding.

This is pretty much what I've been ranting about for the past week or so - I
belive that we should have something like:

Widget::Object (base class)
Widget::Object::Select (pseudo-code for select - contains 'template'
instructions for rendering code and any other internals needed)

Widget::Renderer (base class for renderer [is this needed?  I'm not quite
sure yet])
Widget::Renderer::HTML (class to render pseudo-code to HTML/JavaScript)
Widget::Renderer::WML (class to render pseud-code to WML/WMLScript [or
whatever OpenWave's calling their scripting language])

The programer should select a Renderer object by tying it into the
controller when constructing
(eg. my $wc=new Widget(-options.... -renderer=>"Widget::Renderer::HTML");  )

  Issac