Mailing-List: contact struts-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
Message-ID: <000a01c2f75b$9ec30220$2fbf430a@tmn.capgemini.fr>
From: "Nicolas De Loof" <nicolas.deloof@cgey.com>
To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
References: <000601c2f52a$2c3aae70$0b461bac@grauna>
 <035001c2f52a$7dcaa7e0$2fbf430a@tmn.capgemini.fr>
 <035b01c2f52c$ad56fac0$2fbf430a@tmn.capgemini.fr>
 <OE40m2gUUJpj5ccnume0000bd8b@hotmail.com>
 <001101c2f750$f3e06910$2fbf430a@tmn.capgemini.fr>
 <OE28LrV06n6jRavU4YH0001338c@hotmail.com>
Subject: Re: Too many session scoped form beans!
Date: Mon, 31 Mar 2003 10:00:38 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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" <nicolas.deloof@cgey.com>
> To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
> 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" <nicolas.deloof@cgey.com>
> > > To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
> > > 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: struts-user-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail:
> struts-user-help@jakarta.apache.org
> > > > >
> > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org