You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Toni Lyytikäinen <to...@gmail.com> on 2008/04/21 11:05:48 UTC
Best practise for populating a select from database so that it works for all result types
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.
Re: Best practise for populating a select from database so that it works for all result types
Posted by Al Sutton <al...@alsutton.com>.
Toni,
Isn't your bug a duplicate of
https://issues.apache.org/struts/browse/WW-1963?
Al.
----- Original Message -----
From: "Toni Lyytikäinen" <to...@gmail.com>
To: "Struts Users Mailing List" <us...@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 <
ahardy.struts@cyberspaceroad.com> 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 <
> > ahardy.struts@cyberspaceroad.com> 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 <
> > > > ahardy.struts@cyberspaceroad.com> 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: user-unsubscribe@struts.apache.org
> > > > > For additional commands, e-mail: user-help@struts.apache.org
> > > > >
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: user-help@struts.apache.org
> > >
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Best practise for populating a select from database so that it
works for all result types
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
Did you see this:
http://struts.apache.org/2.0.9/docs/why-didnt-my-action-tag-get-executed-when-i-have-validation-errors.html
I stumbled across it on the wiki. Do you exclude the appropriate 'read' method
on your validation interceptor config? You don't want struts to think that
validation applies - I think it sees the validation error and refuses to invoke
the action.
Toni Lyytikäinen on 21/04/08 12:26, wrote:
> 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 <
> ahardy.struts@cyberspaceroad.com> 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 <
>>> ahardy.struts@cyberspaceroad.com> 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 <
>>>>> ahardy.struts@cyberspaceroad.com> 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: user-unsubscribe@struts.apache.org
>>>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Best practise for populating a select from database so that it works for all result types
Posted by Toni Lyytikäinen <to...@gmail.com>.
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 <
ahardy.struts@cyberspaceroad.com> 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 <
> > ahardy.struts@cyberspaceroad.com> 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 <
> > > > ahardy.struts@cyberspaceroad.com> 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: user-unsubscribe@struts.apache.org
> > > > > For additional commands, e-mail: user-help@struts.apache.org
> > > > >
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: user-help@struts.apache.org
> > >
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: Best practise for populating a select from database so that it
works for all result types
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
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 <
> ahardy.struts@cyberspaceroad.com> 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 <
>>> ahardy.struts@cyberspaceroad.com> 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: user-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Best practise for populating a select from database so that it works for all result types
Posted by Toni Lyytikäinen <to...@gmail.com>.
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 <
ahardy.struts@cyberspaceroad.com> 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 <
> > ahardy.struts@cyberspaceroad.com> 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: user-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: user-help@struts.apache.org
> > >
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: Best practise for populating a select from database so that it
works for all result types
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
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 <
> ahardy.struts@cyberspaceroad.com> 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: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Best practise for populating a select from database so that it works for all result types
Posted by Toni Lyytikäinen <to...@gmail.com>.
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 <
ahardy.struts@cyberspaceroad.com> 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: Best practise for populating a select from database so that it
works for all result types
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org