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]
>
>
