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.
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.
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.
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.
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.
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.
;-)
Stephen
