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