At 10:27 AM 5/29/01 -0400, Stephen Adkins wrote:
>At 09:49 PM 5/29/2001 +0800, Gunther Birznieks wrote:
> >At 12:15 PM 5/28/01 -0400, Stephen Adkins wrote:
> >>Hi,
> >>
> >>Development of a straw-man set of Perl Widget Library core classes is
> >>going well. A Sourceforge project (perl-widget) is in the process of being
> >>set up too. (I will announce when it is set up.)
>...
> >>The state information can be accessed from *any* source by implementing an
> >>appropriate
> >>Widget::<DataSource>::State class (and using some additional,
> >>not-yet-implemented arguments
> >>to Widget->controller()).
> >
> >I think it would be better as a Widget::State::<DataSource> rather than the
> >other way around. From the way you describe it, this is really an interface
> >to getting state information that should be retrieved from a DataSource
> >specific state driver.
>
>I have come to the same conclusion.
>I am changing the design to have three core base classes (other than the
>widgets):
>
> Widget::Controller
> Widget::Config
> Widget::State
>
>A CGI program might run with the following derived classes:
>(These are the initial defaults I am working on.)
>
> Widget::Controller::CGI
> Widget::Config::XML
> Widget::State::CGI
>
>All of these "drivers" may be overridden, as long as the driver you replace it
>with conforms to the interface definition described by the core base classes.
>(Kind of like a Java interface. You would be encouraged to derive from the
>core base classes, but that is not necessary.)
>...
I think this is good.
> >> >
> >> >I don't understand the Widget::Controller. Can you say more about this?
> >>
> >>The Widget::Controller (or perhaps, Widget::CGI::Controller) is the
> >>container class
> >>that you spoke about in your original post. I call it a Controller rather
> >>than
> >>a Container because I envision it being able to dispatch events generated
> >>by the
> >>widgets.
> >
> >Ah. I just want something to contain the widgets essentially. So perhaps
> >from my perspective events aren't necessary and I would potentially just
> >place the widgets into an array representing my HTML screen.
> >
>
>I have found that event handling comes in surprisingly handy even for
>simple tasks.
>Essentially, it allows widgets to define callbacks.
>For instance, the DateDropDowns widget defines an event "change"
>(modelled after the Javascript "onChange" event) that, when triggered,
>concatenates
>the YYYY, MM, and DD back into YYYY-MM-DD.
>The following is working code.
>Notice that the "$wc->dispatch_events($query);" statement takes care of
>whatever widget housecleaning there may be (in this case, recomposing the date
>as a single variable from the three drop-downs).
Oh that's what you mean by events. Hmmm. I don't think this is really an
event as much as a massaging of data back and forth based on the widget
data source interface. I don't think there are really events like
JavaScript, so it seems to me like it would be a bit confusing to apply a
model that is based around a real UI like JavaScript to something that is
purely a simple request/response protocol.
>I had the hunch that everyone's configuration needs would be different.
>Hence the Widget::Config (interface) and Widget::Config::XML (driver)
>design. (Thanks for the input.)
I think this is reasonable. Although if you see my post to Jay, I would
prefer if the core config is then through Perl data structures. And then
all the drivers would map the XML and what have you to the Perl data
structures that are native for speed.
