One of the things I like in your description is the addition of your 'string
keyed' properties. These sound like dynamic properties. We are going to need
dynamic properties as part of ActionForms if we are going to implement dynamic
forms. The problem I've had with the validation discussion involving JavaBean
contrained properties is that a JavaBean isn't dynamic enough to handle dynamic
forms. If I don't know what properties my form will have until runtime, how can
I use a JavaBean?

Just for a different point of view it is instructive to look at forms and
validation in the Barracuda world. Their forms are basically maps (all
properties are 'string keyed'), and any number of Validators can be attached to
each property (for individual validation) and each form (for overall
validation). One can subclass their Form class, as we do with ActionForm.. But
one can also create a form at runtime, adding properties (or FormElements as
they call them) on the fly (for example, from an XML description).

So I like your ideas because they sound more flexible and dynamic than what
Struts currently has, and more flexible than what a straight JavaBean framework
would allow.

Will

> If you want to know more about the mapper, I invite you to read some of my
earlier postings, in which I also sent a sample configuration file. The mapper
framework has been developed independently from the Struts MVC classes. It is
only dependent on these utility packages:
>     - Struts PropertyUtils
>     - Struts Digester (and therefore an XML parser - Xerces of course :)
>     - The Regexp package from Jakarta (used in one validator )
>     - JavaCC/JJTree for parsing custom validation rules
>
> Some of the logic for digesting the XML config file required some extensions
to the PropertyUtils and Digester. The PropertyUtils extension is for supporting
what we have called 'string keyed' properties, which are properties with
accessors of the form getProperty(String key) and setProperty(String key, Object
value). The extensions to the digester were for supporting the resolution of
system entities (only public entities can be resolved at present), and for
adding convenience methods in order to add our own rules to digester. The new
rules we use are called SetTopNow, SetNextNow, SetPropertyFromAttribute,
SetInitFromObjects, CallMethodNow, etc (hopefully these name gives you a rough
indication of what they do).


Reply via email to