As you say, Brian, there are many many situations where the link between actions
and forms are not one-to-one. 75% of the time there is a basic need to execute 2
jobs in any one HTTP request:
(a) process the incoming request and parameters
(b) display the next page
Sometimes (a) will be unnecessary, i.e. just a straight GET, and sometimes (b)
will be unnecessary (as with validation failure) and sometimes they can be
separated into 2 HTTP requests e.g. in the Post-Redirect-Get pattern.
My proposition is that the S2 architecture should ideally accommodate this more.
One should be able to list declarations of all actions, as already happens,
followed by declarations of all forms, which currently doesn't happen, and so
use the Results to link the two together.
I don't know the JSF architecture with its "page/component state saving", Frank,
but I don't think my proposition is along those lines (with state saving).
I'm sure what I suggest could be implemented without forcing any extra
configuration on simple use cases that don't need it, but I see it as a
fundamental issue. I don't think it can be elegantly catered for by the use of
calls to actions from taglibs or by interceptors such as Prepare.
Adam
Brian Pontarelli on 01/01/08 14:45, wrote:
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)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
