Jay,
I think that pretty much describes what I have in mind ...
plus a few other features.
Hopefully within a week or two (based on demands of other *paying* jobs),
I will have a working distribution with most of the bare-bones plumbing in
place and a little configurable date widget implemented.
This will allow me to solicit feedback on the plumbing and concepts
before I go hog wild on implementing a host of widgets.
(In fact, I predict the package will be downright boring for a month or more,
to those who don't want to shape its development, while I get the
concept and the internals right.)
I have done the Widget.pm convenience functions and factory code.
I am working on the Widget::Config class to read XML config data using
XML::Simple.
Then on to Widget::Base a parent class for all implemented widgets.
Then on to Widget::Controller which will be handed a CGI object
(or Apache::Request or whatever using one of the much-commented on schemes)
and dispatches events detected from submit buttons, etc.
Then I do my first actual widget, Widget::HTML::Date.
I'll camp on this while I get lots of feedback.
Stephen
P.S. I have submitted an application for a Sourceforge project called
the "Perl Widget Library". The short name is "perl-widget".
I am waiting for approval from Sourceforge.
This won't hold me up though. I plan on posting distributions on my web site.
At 12:28 PM 5/24/2001 -0400, Jay Lawrence wrote:
>Hey all,
>
>Let me describe what I have been imagining as the ideal widget for what I am
>writing:
>
> 1 - it can look to its environment to determine how to render itsself
> - am I on an HTML page or something else?
> 2 - it has properties that can be set and remain static no matter who's
>using it
> - size, shape, colour, max, min
> 3 - it has properties that are customized by the individual user of the
>widget
> - current value, theme choice,
> 4 - it can tell developers and environments what it can do
> - switch_on, switch_off, increment, decrement, etc.
> 5 - it is capable of persisting from invocation to invocation
> - user 1 sets current_value to x - which always comes back for user
>1
> 6 - it can look to its environment for interhitable properties
> - global theme choice, global font, etc.
> 7 - templating systems know how to call widgets
> - because they always use the same method to display themselves
> 8 - widget can interact with each other
> - increasing value on slider widget changes current record # value
>for database record widget
> 9 - access restrctions
> - users can override some values but not others
> - not everyone can even use this widget, etc.
> 10 - multilingual
> - some things are language neutral others are not - "size" would
>probably be neutral whereas "label" would be language sensitive
> 11 - above all it is easy to use
> - ie/ don't make me set a zillion properties just to make it work!
>
>I am going to throw out a buzzword, gasp, which may serve as a model for
>what we are talking about: JavaBeans. I do feel there is a lot of additional
>complexity there but it is along the right direction IMHO.
>
>If you translate my wishlist into technologies I think I am talking about:
>
> A - a good persistant object management environment
> B - user sessions
> C - integration of widgets (objects) to user sessions
> D - Object API (properties and methods) which are consistant and
>predictable
> E - self documenting objects
>
>This is what I have been looking for/writing myself! I am really eager to
>chip in on this project and get it going ASAP - but do acknowledge the need
>for hearty discussion about what people really want not just my own views.
>:))
>
>Jay
>
>
>
>
