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