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