Toni,
Isn't your bug a duplicate of
https://issues.apache.org/struts/browse/WW-1963?
Al.
----- Original Message -----
From: "Toni Lyytikäinen" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <user@struts.apache.org>
Sent: Monday, April 21, 2008 12:26 PM
Subject: Re: Best practise for populating a select from database so that it
works for all result types
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]
