You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Bill Blackmon <bi...@verizon.net> on 2002/07/29 15:44:06 UTC

best practice question

I have several iterators filled from db calls that will be used across the
app for select boxes,
lists of checkboxes, radio button etc.. In the context of  Struts, would it
be best to load these items as application level items at startup and define
them in the struts-config.xml file with a reference to the class that does
the loading? Any opinions are greatly appreciated.

Bill



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: best practice question

Posted by Eddie Bush <ek...@swbell.net>.
Assuming these are application-level, read-only values, I would think 
you would want to load them at start and make them in application scope 
- yes.  By doing so, not only do you not have to hit the database again, 
but you just reduced your over-all memory footprint too (since you don't 
have to mess around with loading them into a session/request).  Be 
careful about what you put there and how you manage it though ;-)  If 
these are values that change periodically, it may be easiest to just 
take the db hit.  If they are fairly stable (ie. don't change a lot) 
then putting them into the application scope would seem to me a very 
good way to go about it.  Hopefully someone else will have additional 
input ;-)

Regards,

Eddie

Bill Blackmon wrote:

>I have several iterators filled from db calls that will be used across the
>app for select boxes,
>lists of checkboxes, radio button etc.. In the context of  Struts, would it
>be best to load these items as application level items at startup and define
>them in the struts-config.xml file with a reference to the class that does
>the loading? Any opinions are greatly appreciated.
>
>Bill
>
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>