At 09:14 PM 5/31/01 +0200, Issac Goldstand wrote:
> > 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:
> > >...
>[...]
> > >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.
In my opinion, this is very difficult in practice. The widgets should be
atomic and do as little as possible. On occasion, application-specific
widgets would be created to do interesting things like Dates to pull
together several form fields.
However, I think you can accomplish this dispatching to WML and HTML
printing by using a composite widget or a widget container or the widget
controller. It doesn't really matter which abstraction is used. You can use
all 3 by merely subclassing widget and using a composite design pattern
without bloating the original API.
I want to keep the original API simple.
>[...]
> >
> > 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.
I disagree because the *behavior* of widgets in a free form, event driven
environment is much more complex than a request/response protocol. Behavior
differences means added methods and added complexity to the protocol as
well as what a developer has to do to implement a widget.
It's quite possible that it was wrong to call this a widget project and it
should really be HTTP::Widgets because I don't think these are widgets you
want to use in Perl/TK.
>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).
While adding parameters to the constructor is not a problem, I guess I have
a problem with adding behaviors. If you believe that simply adding more
config hooks to allow XWindows to be supported is doable, then we should
just leave it as mentioning this as a supposition and leave it to you or
someone else to prove that the supposition works after v1.x of the widget
set is released.
> >
> > 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
Yes, this is probably a matter of semantics. Basically something else other
than the widget should control what sort of widgets belong to it.
