Craig R. McClanahan wrote:
There's a couple of variations on the theme that are possible, but I can think of at least three layers of something that might be called a "form bean" in the conceptual sense:
(1) A set of typesafe field names and corersponding values where the application doesn't have to worry about maintaining values across requests. - Variation: dynamically add and remove fields as needed - Variation: allow non-typesafe fields - Variation: allow fields that can have multiple values (arrays) - Variation: represent data hierarchically instead of just a name-value map (bean properties, nested expressions, XML DOM, what have you)
(2) The above plus a mechanism to define validation rules (correctness
checks) on the field values that are independent of physical
presentation
- Variation: hard coded logic for validations (i.e. the original
validate() method in Struts ActionForms.
- Variation: pointer to a configured set of validation rules
that is abstracted from presentation considerations.
(3) All of the above plus event handlers for UI events that change the state of the field values -- perhaps in the same bean, perhaps somewhere else.
A type (1) or type (2) form bean is really better thought of as an abstract way to pass the input data for some sort of business transaction between tiers, or within tiers. A type (3) form bean would definitely live in the presentation tier, and not be used between them. For all three of the cases, though, we probably want to invent a different term than "form bean" because that seems so conceptually tied to presentation only. Transaction Bean? Input Bean? Data Transfer Object :-)?
Can't it be just one good old View layer "thing" that maps the properties and it's still called formBean? KISS
Don did not link XMLForms good, here are better links for a real fun read:
http://webservices.xml.com/lpt/a/ws/2003/01/29/cocoon-xforms.html
http://www.cocoonhive.org/xmlform/index.html
I like that Pico is lightest IoC and do not see a need for a Bean Factory, etc.. So there should be some talk of Spring vs Pico.
So far, if it's built on top of
-IoC
-with "XMLFormBean" (as option, since XML can be slow right now, so it needs to support backward compatible FormBean)
-an execute(context) Action iterface,
-chain request procesor filter interfaces
-HTML tag to support XML Submit (including multi row)
-JDK 1.4
-Clear testing interface to major user components.
That could be the broad stroke major center pieces. It is same design as Struts 0.6 with each component refactored, same diagram.
There are several smaller pieces, but if Struts can stay light without too many moving parts, better, people can put arms arround it.
XML config wishes:
- all xml files be able to extend like tiles, like in Validator
- move form beam declaration section to validator, no need to do it 2 times.
- move all tiles xml to struts config, and get rid of tiles.xml
- have a forward to a tile declaration allow you to name the "base" definition and tile to replace, even maybe have tile part of "* forward" or what ever Don's thing is called.
I still kind of think maybe DAO interface should be there, we learned a lot about DAO since.
(I still think one or 2 people should do it in 48 hours from start else... it's design by comittee)
.V
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
