Did you see this:
http://struts.apache.org/2.0.9/docs/why-didnt-my-action-tag-get-executed-when-i-have-validation-errors.html
I stumbled across it on the wiki. Do you exclude the appropriate 'read' method
on your validation interceptor config? You don't want struts to think that
validation applies - I think it sees the validation error and refuses to invoke
the action.
Toni Lyytikäinen on 21/04/08 12:26, wrote:
Yes it shouldn't be affected, but there seems to be a bug that affects this
behaviour, see WW-2599.
https://issues.apache.org/struts/browse/WW-2599
On Mon, Apr 21, 2008 at 2:20 PM, Adam Hardy <
[EMAIL PROTECTED]> wrote:
Yes, I get the picture. If you haven't already, download the source bundle
and look at the examples.
Actually I don't think I understood one thing you said. You're using an
action taglib in the JSP, which invokes the list retrieval. Surely that's
not affected by validation failure? I was under the impression that the tag
simply calls the default or specified method on the action.
Toni Lyytikäinen on 21/04/08 12:00, wrote:
Well, for the retrieval I use stateless session bean injected to the
action
with Spring, like this (simplified):
public User getUser() { return user; }
public String edit() {
user=dao.get(id);
return SUCCESS;
}
So it's nothing special.
The session approach of course isn't ideal, but more a workaround until
the
bug gets solved or I find a better way to do it. The idea is that the
action
is still executed every time the user enters the form from a success
result,
and the non-fresh session based list is only used when validation fails.
I
don't know if you get the idea from this explanation.
Other than that, I found out that the Preparable interface can also be
used
for this, so I might explore that option further.
On Mon, Apr 21, 2008 at 1:19 PM, Adam Hardy <
[EMAIL PROTECTED]> wrote:
I think so - the chain is just a forward inside the same request so you
shouldn't lose the field errors. But I'm just setting up a new website
now
with this approach, so actually I'm as inexperienced as you are - my
previous Struts2 project had a different approach entirely.
You second question regarding retrieval from the DB revolves around
how
you do the retrieval, but you don't say.
I actually cheat like crazy and have a special domain object type
converter which retrieves an Entity from the DB when the HTTP param =
"entity=253" but this isn't the way type converters were meant to be
used.
This doesn't happen if validation fails, because I ordered the
validation
interceptor before the params interceptor in my interceptor stack. And
of
course the edit action doesn't do validation - just the save. (of
course it
throws an exception if you forget to send the id of the entity you
want to
edit).
Generally this makes it easier to deal with nested entities.
But if you just have a simple domain model, go the documented way. I
shouldn't really be saying all this because I haven't got it working
yet :(
Re: lists, you can put them into the request but then you have to
manage
them in case some other user changes them. Plus you will use up
memory. If
you're using a decent persistence layer that has 'second level cache'
which
you can set up when you go live, rely on that instead for caching.
Toni Lyytikäinen on 21/04/08 11:02, wrote:
Thanks for the answer! Does the resultType="chain" approach preserve
the
fieldErrors and the values the user has already typed into the form?
Also,
how do you prevent the edit action from retrieving the entity from
the
database in the case the validation fails?
I also thought about putting the lists into the http session instead
of
the
request, but I don't really like cluttering the session with such
things.
On Mon, Apr 21, 2008 at 12:55 PM, Adam Hardy <
[EMAIL PROTECTED]> wrote:
Hi Toni
there are several different approaches. The one I use has an Edit
action
and a Save action. The Edit action fetches the dropdown list and
puts
it in
the request and results in the form jsp.
The form submits to Save and if validation fails, the Input result
is
resultType="chain" and pipes the request back to the Edit action.
HTH
Adam
Toni Lyytikäinen on 21/04/08 10:05, wrote:
Hello,
What is generally regarded as the best practise for populating a
select
element in a form from database so that it works regardless of
the
action
and the result from which the form is displayed?
I've tried this:
action configuration:
<action name="edit" method="edit" class="admin.Users">
<result>/WEB-INF/jsp/admin/userForm.jsp</result>
</action>
<action name="save" method="save" class="admin.Users">
<result type="redirect-action">
<param name="actionName">list</param>
</result>
<result name="input">/WEB-INF/jsp/admin/userForm.jsp</result>
</action>
jsp page:
<s:form action="save">
<s:action name="listIntoRequest" />
<s:select list="#request.list" />
...
</s:form>
where listIntoRequest looks like this:
public String listIntoRequest() {
List<Item> list=dao.getListFromDatabase();
request.setAttribute("list", list);
return SUCCESS;
}
but the problem is with validation. If the validation fails, and
the
input
result is returned in the in the form processing page (save),
then
the
action tag never executes the method listIntoRequest (see
WW-2599),
and
the
form will not display correctly.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
