It seems like this is a variation on the Preparable theme. I went
through this decision process 9 months ago and decided to use the
<s:action> tag to prepare my forms, mostly for lack of any other solution.
A few more things I ran into that I wanted and could only achieve with
the <s:action>
- Share preparation between actions/forms without sub-classing. This
occurs when you have two actions that share a form (add and edit for
example) and both prepare the form in very similar ways, with some
differences. The common preparation code should be written once and then
accessible by both actions.
- The preparation logic should ONLY be called when the form is rendered.
If I'm remembering correctly, any action that implements Preparable is
called via the interceptor chain during all submissions, including a
valid form submission where the form doesn't need to be prepared again.
The solution should be capable of understanding that the form is being
rendered.
Here's some more ideas for solutions:
1. Modify the <s:form> tag so that if the action it is going to call
implements Preparable than it is invoked prior to rendering the rest of
the form. This would require removing the prepare interceptor altogether
or removing it from the default stack.
2. Add a <s:prepare> tag that somehow calls the preparation code.
3. Make the prepare interceptor more intelligent to understand when
forms are being rendered (is this possible without major headaches?)
-bp
Frank W. Zammetti wrote:
Hi Adam,
If I'm understanding you, what I think you essentially want is the JSF
concept of "page/component state saving" where, talking about an S2 app,
the page, and by extension the "components" on each page (dropdowns,
testboxes, etc), would know how to get their current state and render
themselves.
I suppose you could do that today easy enough by storing the values (and
data, in the case of dropdowns) in session and always render from there.
Maybe not the best answer from a performance/resource utilization POV.
Maybe better would be for each tag in each theme to accept an attribute
that specified the method of an action to call when rendering itself to
populate it's data (default to populateXXX() where XXX is the ID of the
element, so maybe the attribute is optional). Then you could do whatever
you wanted in that method to provide the tag the data it needs to render
the element with the current state. If that method isn't found, just let
the tag do whatever it would normally do now, so as to not break
backwards-compatibility, and let the developer only write the code they
really need to.
(for all I know, S2 already offers this, I don't really know)
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
