Frank W. Zammetti wrote:
Adam Hardy wrote:
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 no JSF expert either frankly, but I was basing my thought on the
part where you said you were concerned with what happens after a
validation failure and the input page being shown again... if you
consider the options in a <select> to be part of the state of that
component (in a sense), then I think it really is about
state-saving... the only difference is that when I say "state-saving",
I'm also talking about the possibility of "prepping" a component,
i.e., looking up in a database for the list of <option>'s for a
<select>, as one example.
Right. So, a form might need to be prep'd by two different actions in
the same way. State saving is only really needed after the form is
submitted. I'm probably not the only one that would think that the
session should be avoided if possible. The flash scope would be a better
location for saved state, but that is only half of the equation really.
And in most cases doing the prep each time the form is displayed isn't
that bad, however sometimes it could be slow and painful.
Currently, most MVCs do this in this preparation inside actions. Rails
for example suggests the design pattern of using a GET/POST inspection
to determine if the form is being displayed or not (brute force in my
opinion). Struts currently suggests using the Prepare interceptor or the
<s:action> to do this.
Another idea is to capture the workflow process and then model that. It
seems like in most cases it is pretty simple:
1. Prepare form
2. Submit form
3. Re-display form if errors or success page if no errors
The URLs for this could be one of three possible permutations:
#1
1. /form (GET)
2. /submit (POST)
3. /submit (using a forward from the submission action)
#2
1. /form (GET)
2. /submit (POST)
3. /form (redirect)
#3
1. /submit (GET)
2. /submit (POST)
3. /submit (forward or redirect)
I think in all the cases step 1 is a preparation and step 3 is a best
modeled via state saving in the flash scope. If the prepare interceptor
only called prepare on GET and the workflow interceptor only called
execute on POST based on an annotation or something, the only thing left
to handle is state saving on errors. This could also be handled via
annotations:
public class MyAction extends ActionSupport implements Preparable {
@GetOnly
public void prepare() {
// prepare
}
@PostOnly(saveOnError=Scope.FLASH)
public String execute() {
// Do form submission
}
}
Something like this might work for all the cases above....
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
