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]
