> Let's focus a bit.
Specifically on requirements more than implementation - *GOOD*
> All I (just my opinion) really want is a widget library for is to get and
> set data in a widget and have the widget subclass know how to display
> itself. In addition, there should be some mechanism for specifying how the
> widget sets up it's internal state based on CGI.pm, Apache::Request,
> Session data or what have you.
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.
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.
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.
> 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 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,
Jay
