Hi, There are many ways of doing this.So first is as the collection is being displayed on screen,make it an attribute of form and popolate it in action on form.So in jsp u will access like a form attribute.
But the problem with this approach is If u get an error and forward back the user to same jsp, u loose the collection data as u are directly going to the screen.So the solution could be have a generic action which will be called in case of errors and the action will populate form with list before forwarding it to same jsp. Else U can have lazy in itialising forms.i.e forms getList emthod itself will call service to get data if list is null.And then in this case ,u can just use an epty action class which does nothing but forwarsd to "success" which is the origicnal jsp.But this action will be mapped with the Original actions form so that the form will use its auto population mechanism to get the list..But i dont like this approach ..just not a good design i think.But very conveninent. Hope this helps, Regards, Shirish -----Original Message----- From: marklowe [mailto:[EMAIL PROTECTED]] Sent: Friday, December 13, 2002 12:12 PM To: struts-user Cc: marklowe Subject: Re: OptionsCollection Okay... But a drop down menu is screen data. And a list of companies is something that will be used more than once. So I have a normal class in my model layer ListCompanies In my UserAction (ListCompanies).getCompanies(); But this Action's primary job is to return a list of users (which it does). As the list is screen data i should be defining this in my form bean? This is something thats being confusing me for weeks. If i've a bunch of collections how can i make them available to iterate tags and select menus, without using useBean (sorry silly design constraint, but beyond my control). Hopefully I'm just being silly, i could really do with some pointers as where i'm missing the point. Cheers mark On 13-12-2002 11:49, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Also i dont understand why u need to access the request directly.I mean why > are > u setting all the collections as request attributes.GEnerally I think the good > design is when u r FormBEan represents the screen data.So in this case > whatever > u need on screen will become attribute of form. > I know it does not make much difference in implemantation but as a design it > becomes pretty straight forward.I mean for an action , if u just look at the > form, u know what is being displayed.So u just populate the form in action. > > Any comments... :-)) > > > -----Original Message----- > From: VEDRE [mailto:[EMAIL PROTECTED]] > Sent: Friday, December 13, 2002 11:44 AM > To: struts-user > Cc: VEDRE > Subject: RE: OptionsCollection > > > You can either use attribute collection="users" for options tag if you store > in request > or you can use name="formName" property="myList" if you have > a getMyList() method for the form(You have to fill call formName.setMyList() > in your action class before forwarding to a jsp). > > > checkout http://jakarta.apache.org/struts/userGuide/struts-html.html#options > if you have not looked at the documentation. > > -rana. > > > -----Original Message----- > From: Mark [mailto:[EMAIL PROTECTED]] > Sent: Friday, December 13, 2002 5:36 AM > To: Struts Users Mailing List > Subject: OptionsCollection > > > Hello > > I've a number of collections already defined that end up being passed to my > jsp's via the request object. > > Users in this case is a map defined in my business logic class that does db > queries. > > users = (ListUsers).getUsers(); > > request.setAttribute("users",users); > > > I itertate through this collection using iterate. But now i want to use this > in a select menu. > > Should I be thinking about making my collection available to my FormBean i.e > making a getMyList() method. > > Thanks in advance > > mark > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
