You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Mr Maillist <dw...@gmail.com> on 2005/02/17 01:29:37 UTC

common information in every view

Hello,

I am building an application that will store menu options in a
database.  These menu options will display on every page in the
application.  I am interested in finding the most efficient way of
doing this.  My options as I see them are:
1. provide a base action for the entire site (similar to
struts-mailreader) that will provide me with a method to load the menu
information and store it in the request.  This option is heavy on
database traffic.
2. still use the base action but store the information in the session
when the user first visits the site.  This option is an awkward type
of cache that might behave strangely with high volume to the site.
3. load the menu options one time from the database and place in the
application scope.  While this is the best memory option (and probably
the most efficient for speed), I'm not sure how I would reload this
after a change was made to the underlying database (or even detect
that a change was made).

I suppose that there is a final option which would be to use a
chaching layer between for database transactions and go with option 1.
 Is a base action the best approach?

thanks in advance for your comments.

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


Re: common information in every view

Posted by Larry Meadors <la...@gmail.com>.
Use a caching DAO layer (like iBATIS), and let it cache the data.
Then, to get the data, use a filter and have it run on requests for
resources that match "*.do" and "*.jsp". The filter can put the menu
into request scope (remember, it is just a reference to the menu, not
the entire menu structure, so it will be very lightweight).

It is then available everywhere, with a global and manageable cache. 

In addition, when you later decide that the menu should be application
or user specific, you have both the URI and the user requesting it.

Another benefit is that if you decide to use some other web framework,
you have no dependency on struts for your menu. The only requirement
you have is that it must be servlet based. Sorry, no .NET allowed. ;-)

Larry

On Wed, 16 Feb 2005 17:29:37 -0700, Mr Maillist <dw...@gmail.com> wrote:
> Hello,
> 
> I am building an application that will store menu options in a
> database.  These menu options will display on every page in the
> application.  I am interested in finding the most efficient way of
> doing this.  My options as I see them are:
> 1. provide a base action for the entire site (similar to
> struts-mailreader) that will provide me with a method to load the menu
> information and store it in the request.  This option is heavy on
> database traffic.
> 2. still use the base action but store the information in the session
> when the user first visits the site.  This option is an awkward type
> of cache that might behave strangely with high volume to the site.
> 3. load the menu options one time from the database and place in the
> application scope.  While this is the best memory option (and probably
> the most efficient for speed), I'm not sure how I would reload this
> after a change was made to the underlying database (or even detect
> that a change was made).
> 
> I suppose that there is a final option which would be to use a
> chaching layer between for database transactions and go with option 1.
>  Is a base action the best approach?
> 
> thanks in advance for your comments.
> 
> ---------------------------------------------------------------------
> 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: common information in every view

Posted by Mark Lowe <me...@gmail.com>.
If the menu is to be the same for all users, then I'd have a servlet
that contructs the menu at startup and places it in the application
context.

Mark

On Wed, 16 Feb 2005 17:29:37 -0700, Mr Maillist <dw...@gmail.com> wrote:
> Hello,
> 
> I am building an application that will store menu options in a
> database.  These menu options will display on every page in the
> application.  I am interested in finding the most efficient way of
> doing this.  My options as I see them are:
> 1. provide a base action for the entire site (similar to
> struts-mailreader) that will provide me with a method to load the menu
> information and store it in the request.  This option is heavy on
> database traffic.
> 2. still use the base action but store the information in the session
> when the user first visits the site.  This option is an awkward type
> of cache that might behave strangely with high volume to the site.
> 3. load the menu options one time from the database and place in the
> application scope.  While this is the best memory option (and probably
> the most efficient for speed), I'm not sure how I would reload this
> after a change was made to the underlying database (or even detect
> that a change was made).
> 
> I suppose that there is a final option which would be to use a
> chaching layer between for database transactions and go with option 1.
> Is a base action the best approach?
> 
> thanks in advance for your comments.
> 
> ---------------------------------------------------------------------
> 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