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]
