I like this approach. It's really smart. The only problem that I see is regarding multiple browser windows. What if the user has more than one browser window on the same "screen" but working on different instances?
For example, the user might have an "order" form for client 1 and another "order" form for client 2 open simultaneously. Using a session scope bean (singleton) wouldn't be recommended in such cases (the same form bean instance for more than one entry form). Anyway, I realize now that the issue is bigger than I thought. Thank you guys for shedding some light on this topic. Jorge > -----Mensagem original----- > De: Nicolas De Loof [mailto:[EMAIL PROTECTED] > Enviada em: Monday, March 31, 2003 5:01 AM > Para: Struts Users Mailing List > Assunto: Re: Too many session scoped form beans! > > > That is just an example, I don't know what MAX value can be > used for the datas you want the user to submit. > > Another solution would be to put form-bean into session scope > and add a "to-be-removed" mecanism : > > When an action puts some form-bean on session scope for > editing, it can set a "to-be-removed" string in session scope > with the form-bean name. > > Every action of the application has to do is job, and look > for this "to-be-removed". If it exists, remove the associated > objet from session. > > This way : > - Your action sets the form-bean for editing, with an > intialized ArrayList as "item" property. > - Jsp generates HTML text fields for items. > - If user follows the correct application behaviour, your > edit-action gets its form-bean from session and can remove it itself. > - If user clicks on menu or use a bookmark, form-bean will be > removed by any other action. > > Nico. > > > Of course, your newest solution is better, but it still > does not feel > > right regarding the MAX_INDEX allowed ;-) > > > > -D > > ----- Original Message ----- > > From: "Nicolas De Loof" <[EMAIL PROTECTED]> > > To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > > Sent: Sunday, March 30, 2003 10:44 PM > > Subject: Re: Too many session scoped form beans! > > > > > > > If this hacking scenario makes you nervous, you can set an > > > acceptable max > > index value : > > > > > > private static final int MAX_INDEX = 100; > > > > > > public void setItem(int index, Object obj) { > > > if (index > MAX_INDEX) { > > > throw new IndexOutOfBoundsException(); > > > } > > > > > > > > > Nico. > > > > > > > Nicolas, > > > > > > > > Your great suggestion makes me nervous ... It is possible for a > > > > hacker > > to > > > > change the index so big that it can hog the CPU, which busy > > > > creating > > empty > > > > node, for each request. > > > > > > > > However, I cant come up with another solution > > > > > > > > Any comments? anyone? > > > > > > > > -D > > > > ----- Original Message ----- > > > > From: "Nicolas De Loof" <[EMAIL PROTECTED]> > > > > To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > > > > Sent: Friday, March 28, 2003 5:19 AM > > > > Subject: Re: Too many session scoped form beans! > > > > > > > > > > > > > Reading my own post I realize this code will throw an > > > > IndexOutOfBoundsException > > > > > > > > > > You need to put 'empty' datas on the List as needed : > > > > > > > > > > protected List item; > > > > > > > > > > public void setItem(int index, Object obj) { > > > > > if (this.item == null) { > > > > > this.item = new ArrayList(index); > > > > > } > > > > > for (int i = this.item.size(); i < index; i++) { > > > > > this.item.add(""); > > > > > } > > > > > this.item.add(index, obj); > > > > > } > > > > > > > > > > Nico. > > > > > > > > > > > I think you can use something like this in a request scoped > > form-bean : > > > > > > > > > > > > > > > > > > protected List item; > > > > > > > > > > > > public void setItem(int index, Object obj) { > > > > > > if (this.item == null) { > > > > > > this.item = new ArrayList(index); > > > > > > } else { > > > > > > this.item.ensureCapacity(index); > > > > > > } > > > > > > this.item.add(index, obj); > > > > > > } > > > > > > > > > > > > This way, when form-bean population occurs, you > will get a new > > > > Collection when needed. > > > > > > > > > > > > Nico. > > > > > > > > > > > > > > > > > > > I'd like to know if it's possible to avoid using to many > > > > > > > session > > > > scoped > > > > > > > form beans. > > > > > > > > > > > > > > I have a bean that contains a collection and I use > > > > > > > nested:iterate > > to > > > > > > > display entry fields on my html:form. When the form is > > > > > > > submitted, > > I > > > > get > > > > > > > an error in BeanUtils.populate(), because the new > bean (when > > > > > > > the > > bean > > > > is > > > > > > > request scoped) contains an empty collection and > populate() > > > > > > > tries > > to > > > > set > > > > > > > the properties of the elements that existed on > the bean of > > > > > > > the > > > > previous > > > > > > > request. > > > > > > > > > > > > > > If I change the bean to session scope, everything > works fine > > (because > > > > > > > now the bean is the same for both requests), but I think > > > > > > > it's kind > > of > > > > > > > messy to have lots of session scoped beans. > > > > > > > > > > > > > > I'd appreciate to have any comments on this subject. > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > Jorge Mascena > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > - > > > > > > > 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] > > > > > > > -------------------------------------------------------------------- > > > - > > > 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]
