Konrad Billewicz wrote:
Sounds like you have some broken flow control there... I would expect that
PrepareEditXYZAction would forward to a JSP, and that the JSP would have a
form that submits to EditXYZAction. EditXYZAction would have 'intput' set
to point to PrepareEditXYZAction which would mean that on validation
errors, PrepareEditXYZAction would be called and would forward to the JSP
again. In other words, (1) sounds wrong.
I understand that the only thing you consider is not right is that decision
edit-or-update is made in PrepareEditXYZAction, not in EditXYZAction. I have
made this choice knowingly for several reasons:
>
1. Prepare action should be responsible for preparing parameters,
compleately. I could image that there is another action which uses
complately different mechanism for getting parameters (for example getting
pure IDs from some source) but executes the same Edit action. I'm not sure
is it right idea but it sounds good in my opinion.
I'm not sure what you mean with this. Normally, you have an action which
'prepares' the data the view will need to render, which then forwards to
a JSP; and an action for the JSP to submit to, which performs the
desired application logic for the form submission.
If you mean that you need to do some of the same setup work before
displaying the view as well as before processing the form, you can
either pass that data through the view so it's available from the
request in your edit action, or have a helper class that both actions
use to do that common setup work.
2. I had problems with validation. My form is multi-level and I want
validation only when parameters are complete. In mappings of Edit action I
have validation set to true, so any partial data form is rejected
automatically. I don't tend to resign from automatic validation bacause need
of such a resign seems to be, in my opinion, a design mistake.
So you have a multi-page wizard type scenario? I.e. one view which
repeatedly submits to the same action to render the next page of the
wizard? You can still have the final page in the flow submit to a
separate 'the wizard is complete, process the submitted data' action.
Currently I had solve my problem differently and I'm quite satisfied with
it. I have made third action, very ganeric, named RelayAction. More about it
can be found at [1]. What do you think about this solution?
[1] http://www.jguru.com/faq/view.jsp?EID=995474
Looks like just another way of managing control flow: a 'switching
action' that works by chaining to another action, as opposed to by
delegating to a method within the same action as DispatchAction does.
That needs to be used with caution; action chaining is generally
discouraged. If I were to use that technique, I'd still carefully
separate preparing and rendering the view from processing the data
collected by the view.
It may help to remember that forward names are *logical outcomes* of
action processing, not simply an alias for a URL. Ted's article doesn't
make that distinction very clearly (well, at least not that particular
article :-)
Can you post your action mapping definitions from struts-config, and the
relevant bits of your JSP code (specifically the html:form tag)?
Mappings:
Well your JSP references an action you didn't show :-) But given what
you say above, I think what you're doing is calling an action with
forwards to a JSP; having that JSP submit to the same action; and having
that action forward to another action to process the form. If validation
fails on the second action to forwards to the first one (via it's
'input' mapping), which promptly tries to forward to the second one
again because it sees the same 'dispatch' parameter in the request.
This is one reason why action chaining is bad :-)
What you should do instead is have the JSP submit directly to the second
action and remove the action chaining logic from the first action. Then
if the edit action fails validation and forwards to the first action,
it'll just redisplay the JSP as intended.
If you really need to execute (some of) the same logic in both actions
see above: move it into a shared helper class.
HTH,
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
