Stephen Adkins <[EMAIL PROTECTED]> 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.
Actually, it could be. It would allow for general templates of widgets that
are not specific to any particular format (thinking of the standard template
library in C++). Perhaps overloading the stringizing operator for output... >
:)
>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.
The actual output code could be controlled by a configuration option -- if the
configuration is help in another object that the widget can query, then the
caller will not *have* to know, though it could know, which format the widget
will be rendered as.
>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.
Agree... but I don't see why we can't push this down as low as possible so we
don't have to know how we are rendering until the absolute last possible
moment.
>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.
Stretching the paradigm can be good. My mind was going along the same
direction -- figuring out an implementation is a bit of a problem at the
moment though.
>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.
Provide a way to query capabilities of the underlying technology -- how big is
the screen, remote vs. local, degree of user interaction available, etc.
--
James Smith <[EMAIL PROTECTED]>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix
