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
>