At 05:52 PM 5/28/01 -0400, you wrote:
> > Let's focus a bit.
> Specifically on requirements more than implementation - *GOOD*
I think you misread my intention. I think the requirements are simple and
fairly clear except for some interesting enhancements people (includign
yourself) propose on the list. I'd like to get a set of objects out more
quickly that only do a few things well and in a small lightweight interface.
>Could I paraphrase or reinterpret what you have said to be base classes
>for handling widget properties and data sources?
>
>In the web world I see data coming from:
> static widget properties - design/configuration values
> user supplied values - Session and Request values
> data sources - RDBMS, LDAP, yadda
>
>In addition I do see a variety of flavours for this data: scalar, array,
>hash. Me, I want even more exotic flavours such as language sensitive (The
>lable property check's user's language choice and will give them back the
>lable in the right language). In order for a widget set to be useful we have
>to agree on how to pass around a certain set of potentially complex data
>types.
>
>READ: robust base object class with potentially fancy strategy for
>rationalizing a number of data sources and data structures.
This is very vague to me. It just doesn't sound very concrete enough. I
think an interface to be able to do reference to a hash where values are
either ref to an array or scalar is good enough initially.
>Additionally - when it comes to widget-specific actions - such as rendering,
>then you're seeing this as a subclass (or group of methods) that has been
>defined by the widget creator.
> ie/ widget->render - generic method that checks container and calls
>appropriate render subclass for this widget
> since container is HTML return widget->render_HTML or whatever.
I think breaking out render subwidgets is too complex for my tastes.
>READ: object hierarchy. Objects check their parents for hints on how to do
>things - like pick the form to render themselves, etc.
>
> > 1. Data Validation logic. No, this does not belong there. This is a
> > separate library. I already have a rich Data handling library in my
>toolkit
> > that I intend to plug widgets into. All I need is to be able to get widget
> > data from the data handling/validation library.
>
>If I place a widget into my user interface and allow a user to specify a
>value how I am I to implement validation?
>
>ie/ Widget has property "choice" which can be "1","2", or "3". If the user
>supplies any other value I want choice to be NULL and raise an error.
>
> A - does controlling application logic enforce choice validation
> B - does widget have property information to say that choice property
>must pass some validation process?
>
>I like B because it further compartmentalizes the behaviors of the widget
>within its own specification. The source of the valication routines can be
>external to the widget and classes but the validation rules would be
>specified within here.
This is exactly why config should not be part of the widget library except
as a side optional item. You can make your config also optionally configure
data handling rules, but mine might not. Then its up to your app toolkit
(if it wants to) to set up the data handler methods to be called when the
form is submitted to the CGI based on that config.
> > 2. External display stuff. No, I just want the widget to know how to draw
> > itself and only itself. It's up to a template language plugin like TT or
> > some other template language to provide the wrappings. Or it can be a
> > toolkit like your drawing forms library -- but the widget itself shouldn't
> > have to know about external decoration around it. Just how to draw itself.
>
>If one is to create an HTML form on a web page then all of the form elements
>should actually be contained within in a FORM container. The FORM container
>can then facillitate the correct development of HTML etc.
>
>If the widgets are used within another context then the FORM container might
>be necessary or it might not. But it is usually easier to ignore than try to
>backpeddle and whack stuff in after its kinda too late.
It's pretty rare for this to be an issue. If it is, I would rather see a
form become a widget that is linked to another widget if you really require
functionality like this.
> > It's possible, but I am not quite sure because the primary complexity
>seems
> > to be the data handling (which I have already in a separate abstraction)
> > and the UI generation which I have already in Template Toolkit. So all I
> > really want is an object abstract called a Widget along with a
> > WidgetCollection to allow grouping widgets together that belong on a given
> > HTML page.
>
>The way I am seeing a solution come together is somewhat different. First of
>all I am now tending to really really really want to work with persistant
>object collections. As my application needs new widgets I instanciate a new
>object of that class into the app's collection of objects. Then I can set
>its properties as I wish. From that point onwards I can just boss the
>widgets around and make 'em do what I want.
>
>If you do not want to work with persistent object system then you can come
>up with any number of tactics to define your widget objects as needed: XML,
>inline code, Data::Dumper, etc.
>
>A few of my thoughts,
I think your thoughts are interesting but way too complex for my own
interests. The stuff that you describe that's complex is also described
anecdotally. I really shudder to think what would happen when it is really
coded and when it is really put in practice. I just would hate to have a
really complex library that takes people a long time to grasp and
understand because it is hyper broken out.
Let's put it this way, I have actually used widgets for the last 6 months
in real world applications using JSPs and widget libraries in Java. I can't
tell you what a joy it is to work with something so relatively simple and
just easy to put things in a page.
And Java is known for being overdesigned and complex. :)
So I guess I am really against bloating the feature set and the API of
something that should be relatively simple and that I could enjoy if it
actually comes together in a couple weeks instead of being something where
I have to have a Visio to understand the hierarchy at all.
What I am NOT against is you stating what would be cool. So I think that is
useful. I am not intending to be disparaging.
But I am against implementing all these features right away so there's
gotta be some choice. And I really do think that some of the warnings about
thinking things through are not really warranted because I have been
working with this stuff on another platform. I just want Perl to enjoy the
same feature. There is some room for adding a few more fancy features, but
I do not believe everything in this mail can be accomplished.
One other thing. For me, this must work on mod_cgi. And if it's going to
cause long load times because the hierarchy is complex and there's a ton of
interfaces to do everything then that will make me unhappy. I am willing to
slow down a bit for mod_cgi in adding a widget feature, but not a lot.
Definitely should not be the equivalent of loading a second copy of CGI.pm
for a normal app.
