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

[Gunther B. <gu...@ex...>]

At 11:19 AM 6/5/2001 -0500, James G Smith wrote:
>Gunther Birznieks <gu...@ex...> wrote:
> >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.
>
>Then perhaps the widgets are being too closely tied to the end result.  The
>Widget::TextField should know which way is best for the environment in which
>it is being rendered.  Why force the coder to figure out the best way to put
>up a text input field?  That complicates the higher-level coding and we have
>lost the abstractions we are trying to put in place -- the developer has
>gained nothing from using the Widget set except having to learn yet another
>way to do things.

I think the statement here "gained nothing" is really a bit harsh. There 
are many other features of widgets that are quite useful as indicated here 
before. If you think that they have gained 'nothing' after the previous 
conversation then I am not sure what to say.

>The Widget::Thingy class will know which of it's classes to use for 
>rendering.
>  For HTML, it might use Widget::Thingy::HTML while in WAP it uses
>Widget::Thingy::WAP.  The Widget::Thingy class itself contains the logic used
>to tie itself together, not actually render itself.  If it has to worry about
>which way to render a constituant widget, then it's not using a sufficiently
>abstract widget.
>
>Hopefully widgets will be more abstract than just Perl wrappers around the
>HTML set of input objects.

Well, I don't think this was my stand. This is a bit overstating a simple 
argument. Really it is the difference between a widget that is a text field 
knowing what to output for HTML vs WML and a widget that is a WML textfield 
vs a widget that is an HTML text field.

I prefer the second form. Each widget should encapsulate the minimum atomic 
operation. Note, that with a composite pattern you can simply wrap other 
widgets if you want to in order to do more more complex logical feats, but 
overloading the widget library to have to include hooks to understand when 
it should output HTML vs WML vs something else feels quite cumbersome to me.

Not to mention that in real world practicle that WML screens are often 
designed extremely differently from HTML screens. You really can't just 
replace the widget 1-1. In most cases the entire presentation has to change 
by nature.

Also, I can think of yet another more useful difference which would not be 
covered by introspecting the browser type -- that of displaying 
display-only widgets and editable widgets. This is something theoretically 
really useful because many applications require support for this -- even if 
they are just HTML.

Consider a WebDB. A WebDB has a search screen which will produce a set of 
tabular results from the search. These results will usually be plain text 
representations of the column values for all the displayed records. But if 
you click on a modify button, the next screen that is generated should 
place the editable form of column widgets on the screen.

So you would have

$widget->displayReadOnlyForm();

$widget->displayEditableForm();

Yet, I would still ague, even with the demonstrative usefulness of this 
addition to the API, to please not include it in the core atomic widget API.

I think we can all come up with many different ways of doing this part of 
the API and therefore it should not be included in the core atomic widget.

Rather, I think it is better off handled with wrappers (composites) that 
suit the logic that the app developer may want. And in many cases this 
should be handled by a container being configured for particular 
screens.  Usually when there are many ways to arrange something (like 
widgets) the appropriate design pattern is to leave it to external 
containers to deal with the decision making process. Otherwise you are 
tying it too much to your own way of making applications which isn't 
necessarily how others write applications.