Re: [Perl-widget-developer] Widget.pm design

[Issac G. <ne...@wr...>]

> I disagree in general with this. Having coded a lot of WML and HTML myself
> for a local mobile company, I can say pretty strongly that I do not
believe
> in a 1-1 mapping between elements in WML and HTML except in a very loose
sense.
>
> You really have to code the whole template very separately for WML vs HTML
> and the choice you make (eg textfield vs textarea) is very different on
WML
> vs HTML.
>
> 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).  Therefore,
it's silly to make the developers' lives hard by having them have to start
picking different classes for HTML, WML, Curses, etc.  It also makes Widget
developers' lives hard - if we could come up with some templating language
that _WE_ could port across the different rendering environments, then not
only could the Widget::Base inheriting class developer not have to worry
about porting their widgets across environments, but Widget::Renderer
inheriting class developers could easily add Renderers for ALL 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).

each inherited renderer must contain implementation for the whole list of
commands and no more.  renderer developers should be discouraged from
writing an 'enhanced' language for his/her renderer - this will only cause
incompatibility probelms.  As long as we're on sourceforge, I'd say that if
someone thinks we're missing a template command, it should be brought to the
mailing list for a suitable period of time (2 weeks?) for consideration.  If
accepted, we'll update the base renderer object, and patch all inherited
objects to include it.  As long as it's a "recommended" command, this is
easy - we just patch it to display a warning, until the original developer
gets a chance to patch it better...

Sorry if I may have bended the "two topics in one post" rule a b it here,
but the two were very closely related so I felt it neessary to express it in
one post...

  Issac

Internet is a wonderful mechanism for making a fool of
yourself in front of a very large audience.
  --Anonymous

Moving the mouse won't get you into trouble...  Clicking it might.
  --Anonymous

PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B