> 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
