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.
>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 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.
>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.
>Note: This allows you to write physical widgets which are tied intimately with
>a particular browser version. The Controller and Config mechanism would
>*allow*
>you (not force you) to write an application that falls back gracefully and
>uses
>other physical widgets for different browsers. A "Menu" widget using all
>sorts
>of whiz-bang DHTML on IE 5.0 could be rendered sanely using a different visual
>paradigm on an NS 2.0 browser (or Lynx, or Curses!) using a different
>physical
>widget.
>
>This brings us back to the debate over the display() method vs. the html()
>method.
>Every widget class only runs in a certain environment.
>An HTML widget is being told to emit HTML, hence the method name "html()".
>In addition, the display() method really does not display anything.
>It simply returns HTML. It is only displayed when the HTML is printed to
>STDOUT.
>That is another reason why I think the display() method goes on the Controller
>something like this: $wc->display(@widget_list).
>
>(As a reasonable compromise, I think what I will probably do is add a
>convenience
>method "display()" which calls the html() method for Widget::HTML::* widgets.)
>
>As always, thoughts are welcomed.
>;-)
When I use widgets, I will use them the same way as I have used them in
Java. I will make a widget tag for a template language and the widget tag
will know to call the widget's display method. If I want to use the WML
widgets instead, then I will make a WML JSP page and put all the WML widget
equivalents on there instead.
It's a simple model that works.
