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.