[Perl-widget-developer] Fw: Real Widgets and Template Languages

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

----- Original Message -----
From: "Issac Goldstand" <is...@ma...>
To: "Gunther Birznieks" <gu...@ex...>; "Stephen Adkins"
<ste...@of...>
Cc: <per...@li...>; <mo...@ap...>
Sent: Thursday, May 31, 2001 21:14
Subject: Re: Real Widgets and Template Languages


> > At 12:31 PM 5/29/01 -0400, Stephen Adkins wrote:
> > >At 09:53 PM 5/29/2001 +0800, Gunther Birznieks wrote:
> > > >At 05:17 PM 5/28/01 -0400, Stephen Adkins wrote:
> > >...
> > > >>    $widget = $wc->widget("first_name");
> > > >>    print "First Name: ", $widget->html(), "\n";
> > > >
> > > >A widget type has already been defined. So I don't see that the
method
> to
> > > >output it's display should be called html() which is, well, HTML
> specific.
> > > >I prefer
> > > >
> > > >print "First Name: ", $widget->display(), "\n";
> > > >
> > > >Since widgets are components that know how to display themselves
> whether
> > > >its WML or HTML or whatever.
> > >
> > >This is a philosophical design decision that I have been struggling
with.
> > >The widget does indeed know that it should generate HTML, so it could
> have
> > >a method, $widget->display(), $widget->draw(), etc.
> > >
> > >However, this implies that the widget has the freedom to decide how it
> > >should render itself and that the caller does not need to know.
> > >This is not correct.
> >
> > I think it is correct. The widgets are specific to the technology like
> HTML
> > or WML or whatever. It's up to your config in the Controller to
determine
> > which widgets you are putting into the controller.
> >
> > If you want to display both WML and HTML, you would create a WML
> controller
> > and an HTML controller. Note that the controller itself doesn't know the
> > difference, but you just are using it as a collection mechanism to group
> > together like-sets of widgets.
>
> This is true, but that's not a really good design plan.  Now I still
haven't
> quite understood how the different base classes work together, so I can't
> suggest a specific implementation strategy yet, but IMHO you should be
able
> to create Widgets dynamically for any target UI, with widgets that are
> nativelly unsupported in a specific UI (eg, WML vs HTML) doing some
default
> action (AUTOLOAD somewhere?).  Now I agree with Gunter in that
> $MyWidget->DisplayHTML() vs $MyWidget->DisplayWML() is the wrong way of
> doing it.  But I was sorta thinking along DBI's way of doing things in
that
> you load a "driver" first - the "driver" being the UI link, and then
> $MyWidget->Display() would automatically use the correct "driver" for
> outputting stuff.
>
> Before I go any further, I should mention that I still haven't understood
> all of the terms that Stephen uses when describing the Widgets, so if I'm
> repeating something here that anyone already said, please let me know what
> part of the existing interface I'm describing...
>
> Now, the only problem is how to make the "default" actions (for Widgets
that
> are unsupported by the "driver").  I need to think about this a bit more,
> but it'll probably take an AUTOLOAD per-widget and/or a specific function
> (not AUTOLOAD) per-driver...
>
> > >The caller in this case has already cooked up a bunch of HTML and is
> > >counting on the widget to produce HTML which can be inserted.
> > >The widget does *not* have the freedom to render any other way.
> > >This is why I have (sort of stubbornly) stuck with the $widget->html()
> > >method despite the unanimous suggestions for a $widget->display()
> > >method.
> >
> > and then also ->wml() and ->X() and whatever else? This does not seem
> right.
> >
> > >I do believe there is a place for a display() method, but it is at
> > >the controller level.  The is the level at which the caller may not
> > >know what technologies are being used by the widgets.
> >
> > Yes its not at the controller level. It is at the widget level. So you
> have
> > Widget::WML::TextField and Widget::HTML::TextField...
> >
> > And the firsto ne would go into a controller that is set up to contain
WML
> > widgets in general and the second would go into a controller that is set
> up
> > to contain HTML widgets in general.
>
> This is also doable, but only if it's transparent to the user.  In other
> words, the developer _using_ the widget would have to mkae a
> Widget::TextField, and only when it was _rendering_ the Widget, would the
> libraries internally read the information in Widget::HTML::TextField or
> Widget::WML::TextField - otherwise,  it's just not worth making "generic"
> widgets.
>
> > >This whole discussion brings out two other important design decisions.
> > >
> > >   1. What are the UI technologies we really wish to support?
> > >      (i.e. is this *really* a Widget or an HTML::Widget library?)
> > >   2. Which classes represent Logical Widgets and which Physical
Widgets?
> > >
> > >1. TECHNOLOGIES
> > >
> > >I propose that the following technologies will have supporting
> > >Controller/State/Widget combinations to make this not just another web
> > >widget library.
> > >
> > >   * CGI/HTML          - a web application
> > >   * mod_perl/HTML     - similar, a web application using mod_perl
> > >   * WAP/WML           - driven from a WAP device
> > >   * X11 (Gtk-Perl)    - an X windows application
> > >   * Curses (terminal) - a screen-oriented terminal application
> > >   * Term              - a line-oriented (scrolling) terminal
application
> > >   * Cmd               - similar to Term, but the state must be saved
> > >between each cmd
> > >
> > >(I know I'm stretching the paradigm a little bit here, probably beyond
> what
> > >is reasonable.
> > >If you don't think one or more of these is a good idea, please keep it
to
> > >yourself.
> > >I have a vision for it, and even if it's not very useful, it will shape
> the
> > >"abstractness"
> > >of the design elements. On the other hand, I would welcome suggestions
> for
> > >additional
> > >UI technologies that I might consider supporting.)
> > >
> > >One of the primary design rules is to *not* fall into the "least common
> > >denominator"
> > >trap.  Many cross-platform application frameworks have done this and
> failed.
> > >Rather, the design goal is to *enable* the widget to fully utilize the
> > >capabilities
> > >of the technical environment it is in.
> >
> > I very much disagree.
> >
> > Least common denominator is not a trap. It's a design decision. This is
> why
> > design patterns have consequences. Different design choices mean
different
> > things. I think you ask for failure and bloatedness when you try to ask
> too
> > much of an API.
> >
> > The attempt to make this widget library even encompass X-Windows and
> normal
> > GUIs is frustrating to me. As I have mentioned in a previous mail, I
> > already use this technology on Java and JSPs. This is taking a small and
> > simple concept and blowing it way out of proportion.
> >
> > Ok, that's the end of that rant and rave.
> >
> > Here's my constructive criticism. The design constraint on the widgets
> here
> > is that you should assume a request/response model through HTTP for this
> > library and basically assume compatibility with template libraries that
> use
> > HTTP as a medium.  X windows and curses and all that kind of stuff is
not
> > appropriate and will confuse the API from an HTML perspective.
>
> I disagree.  I think that by having dynamic parameters for the widgets, in
> conjunction with my "driver" idea, this can be made a lot more flexible
> without these problems.  It would take planning out, but if we make the
> "snap-in" environment work correctly, then simple users who want easy HTML
> can do that easily, while a developer writing a template that will display
> on X-Windows as well as it will on a cellphone screen gets the HUGE
benefit
> of constant widgets in a single template.  Now for advanced stuff, we may
> very well need complex parameters - possibly even on a per-widget basis -
> but this should be on an "extended parameters" basis.
>
> Since I'm actually starting to trip over my own words here, let me try to
> illustrate with an example (note that I'm pulling methods and objects out
of
> thin air - the idea is to illustrait the idea I brought up, not
necessarily
> offer a draft of it):
>
> Complex Widget:
>
> <Widget type="textbox" maxsize="50" length="25" X-Offset="40"
Y-Offset="20"
> TabStop="True" TabIndex="3" name="text1" value="some sample text"
> tooltip="Enter some text here"/>
>
> Now, let's say that the developer prints this with the HTML "Driver" -
this
> could do something like:
> <INPUT TYPE="TEXT" MAXLENGTH="50" SIZE="25" NAME="text1" VALUE="some
sample
> text" onMouseOver="Window.status='Enter some text here'"
> onMouseOut="Window.status=''"/>
>
> And in some other GTK-based environment, it could do  something like:
>
> Label text1;
> with (text1)
> {
>     .Length=50;
>     .Width=25*XCharSize; // The *XCharSize would have to be defined by the
> driver or by the native interface
>     .Height=1*YCharSize; // This would be a default setting "plugged in"
by
> the driver
>     .Value="some sample text";
>     .Left=40;
>     .Top=20;
>     .TabStop=1;
>     .TabIndex=2; // 3-1 for 0 based - also defined by the driver...
> }
>
> Now, neither of these cases used _all_ of the widget parameters - a simple
> HTML designer could have produced an IDENTICAL widget by doing:
>
> <Widget type="textbox" maxsize="50" length="25" name="text1" value="some
> sample text" tooltip="Enter some text here"/>
>
> This shows a few things, actaully.  First of all, the widget can get as
many
> or few parameters as the developer wants to supply it with - extra
> parameters will be discarded by drivers who do not understand them, and
> missing parameters will be supplied with "default" values wherever
possible.
> Now, I would suggest designing this such that the developer only interacts
> with a Widget::textbox.  Internally, there would have to be a
> Widget::HTML::textbox and a Widget::GTK::textbox, each with the
UI-specific
> rendering instructions...
>
> The only problem is making sure that the overhead is kept to a minimal -
in
> that as few feautres that are not actually NEEDED for the specific
> implementation are loaded as possible (eg, a user using only certain
> elements in HTML will only load those elements, and only HTML, while if he
> wants WML, it will also incur WML generic overhead too).  I think this
> approach should satisfy both the wants to keep the widgets as generic as
> possible, as well as Gunther's wanting to keep the widgets as simple and
> easy-to-use/understand as possible (for beginners, at least).
>
> > >This brings me to the next topic.
> > >
> > >2. LOGICAL vs. PHYSICAL USER INTERFACE ELEMENTS
> > >
> > >I have spoken about the separation of the logical and physical user
> interface.
> > >This facilitates applications being written to the logical interface.
> > >The physical UI is then determined at a combination of
configuration-time
> > >(config file) and run-time (user preferences, browser capabilities,
> etc.).
> > >
> > >As the library has developed, it has become clear that the "logical UI"
> > >is really only a figment of the coder's imagination, represented by
code
> like
> > >
> > >    $widget = $wc->widget("file_name");
> > >
> > >However, the Widget::Controller ($wc) decides (based on config and
> runtime
> > >values)
> > >which *physical* UI widget is returned.  This could be a drop-down list
> box
> > >(<select>),
> > >a text box, a set of radio buttons, or some sort of complex/compound
file
> > >chooser widget.
> > >
> > >So when you code a widget, it is a physical widget.  The selection
> between
> > >physical
> > >widgets in order to fulfill the requirements of the logical widget are
> all
> > >decided
> > >by the Widget::Controller.  Similarly if the Controller is a
CGI/mod_perl
> > >Controller,
> > >it will only choose HTML widgets, whereas if the Controller is a WAP
> > >Controller,
> > >it would only choose WML widgets, etc.
> >
> > Yes. A widget should be *physical*. And it is possible for controllers
to
> > be logical and understand how to call upon WAP widgets and HTML widgets
> > when the time comes. Or it can be as simple as I mentioned before where
> you
> > just define different containers -- a WAP container and an HTML
container.
> > And then that's it. It's up to the applicaiton to choose to use the WAP
vs
> > HTML container, not the container itself to understand what browser it
is
> > running under.
>
> I think the idea here is similar (if not the same as) my "default control"
> idea, in that if a Widget is requested in environment that doesn't
actually
> support it, the design could be "engineered" in a different manner
producing
> a similar result (similar to hardware vs software 3D graphics rendering -
> we're essentially creating a HAL for our widgets) - or if that's
impossible,
> it would report it either to the programmer, the end-user or both.
>
>   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
>
>