Re: [PW-dev] widget progress continues

[Stephen A. <ste...@of...>]

Hi,

At 11:08 PM 10/3/2001 +0800, Gunther Birznieks wrote:
>That's really cool! I'd love to hear what you felt the weaknesses and 
>strengths were.
>

Gunther asked, so here are some comments.

They probably won't mean anything to anyone because my head is buried
in the internals. And I'm not really in a state to take a lot of
community feedback yet. I'm just trying to keep you abreast of what
is going on.

Strengths
 * true visual component model
   Widgets can be written not knowing how they will be used and then
   assembled via coded containers and config file. Complex widgets
   can be created from simpler widgets.  The complexity of the
   implementation is completely hidden.
 * UI state maintenance
   State is maintained cleanly across HTTP requests, but each widget
   has a reference to its own state without knowing about the other
   widgets' states.  State maintenance is done without server storage,
   cookies, or URL rewriting. (i.e. <input type=hidden>)
 * Container-element relationships
   Both the parent-child inheritance and container-element containment
   relationships are implemented
 * Event bubbling
   Events can be processed by the widget or bubbled up to its
   container for processing (i.e. a TreeView widget wants to
   process open() and close() events on its folder nodes without
   bothering its container.  A select() event on one of its leaf
   nodes needs to be bubbled to the container widget for processing.)
 * Attribute configuration
   A tremendous amount of information is determined at runtime via
   configuration data.  The only things that have to be know to a 
   developer about a widget are its name and a set of methods it is
   assumed to support.  Any number of implementations of this interface
   may be configured to go at runtime.
 * Attribute absorption
   Attributes can be absorbed from the container widget, enabling the
   promise of themes (styles) and internationalization.

Weaknesses
 * my desire to do state maintenance strictly by <input type=hidden>
   variables with no server-side storage is showing limitations
   (particularly for complex, frame-aware widgets).
 * I need to refine how I separate and combine the configuration
   data with the runtime user data.  I don't want to copy all of the
   configuration data (which could include large multi-language
   dictionaries) into each session, but I need to merge what was
   configured with what has been overridden.
 * I require too much overhead in my simplest widgets. A simple
   non-active, single-valued entry widget (i.e. <input type=text>)
   should be incredibly simple and fast with virtually no memory
   footprint.  I have ideas for making simple widgets simpler
   while continuing to provide power to 
 * Simple inter-widget state setting could be made much more
   efficient (I think). I have to instantiate a widget to set its
   state currently, whereas it might be much more efficient to 
   tell the controller to do it.  The controller can use its
   knowledge of the internal state of widgets so that the widget
   doesn't even need to be instantiated.
 * I currently required widgets to handle the x() and y() events
   associated with image buttons (<input type=image>) instead of
   doing it for them in the controller.
 * I don't currently have a Message Authentication Code (MAC) on
   the Storable/MIME state which I embed in each returned page.

Stephen