perl-widget-developer

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

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

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.


-- 
Cees Hek

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

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