I think your point below about form-beans being part of the framework is the "nub of the crux" of the problem. There's not enough there for novice users to distinguish their responsibilities from those of "normal" Java Beans.
Customarily, object-oriented frameworks are extended solely in terms of behavior (it's that roles and responsibilities thing again). In the case of form-beans, though, the Struts framework is defining a whole new kind of object. The provided superclass has well defined capabilities, but only vaguely defined responsibilities.
If ActionForm was defined as an interface that specified methods for getting and setting fields with String names and String values, its responsibilities would be clearer. Consequently it would be possible both for novice users to use the default implementations more reliably, and for competent engineers to provide alternative implementations.
<CONTROVERSIAL-CLAIM>
In effect, by piggy-backing on beans-properties introspection for the sake of convenience, your novice users are lured into thinking that form-beans are beans, but they're really intended to be much more restricted in scope.
So, if you were to introduce an interface (say, IActionForm) that more clearly stipulated the intended roles and behavior, and documented the heck out of the default implementation to advise novices not to use the rest of beans capabilities indiscriminately, you might end up with a better framework for all classes of users.
</CONTROVERSIAL-CLAIM>
And, of course, that would also make it easier for me to integrate JPlates more fully with Struts. As to your question about whether JPlates objects could still be used for more than a single request, the answer is definitely yes. JPlates objects can be kept directly in the session scope, or they can be referenced by form-beans, etc. I'm currently employing both of those approaches, and I'd still like a more straightforward abstraction for form-objects that didn't require an awkward (and arguably unnecessary) delegation.
This is addressed (somewhat briefly) in my presentation about design-pattens in template-based apps. There's a link to it at http://www.jplates.com, in the documentation page.
-- Dan
Craig R. McClanahan wrote:
...
In particular, I want to be able to use JPlates objects (see http://www.jplates.com ) as ActionForms, since that would allow me to encapsulate the full behavior of a form in the object, instead of just having a place to put the data. I can already use JPlates in place of JSPs for rendering (which is wonderful!), but I'd have a more consistent solution if I could use JPlates objects for my ActionForms as well.
...
Well, like I said, I use JPlates easily in place of JSPs for rendering, because JPlates comes with a dispatching servlet similar to yours, allowing JPlates to be addressed using URLs just like JSPs. So in that way, JPlates works with Struts just as well as Velocity.That was the design goal. What people resist, though, is the notion that form beans belong to the framework, not to the view technology :-).For ActionForms, though, I can only use JPlates instances by delegation from an anstance of an ActionForm subclass, which is ok, but not idea. I'd rather be able to implement IActionForm from a JPlates class and delegate to an ActionForm if necessary.If you intermix the presentation capabilities of a JPlates object and the data storage capabilities of an ActionForm, doesn't that mean you would have to give up the (currently supported) capability to use the same form bean for more than one view page? Craig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
