Re: common information in every view

2005-02-17 Thread Larry Meadors
The only thing I do not like about that solution is that it marries you to both Struts and Tiles. Both are fine tools, but I do not understand how they simplify the process enough to justify using them over a simpler filter+jstl+tiles solution. Larry On Thu, 17 Feb 2005 18:45:31 +0100, Mark Low

Re: common information in every view

2005-02-17 Thread Mark Lowe
I agree that tiles controller is the nicest option in terms of design, but last time i use tiles controllers for exactly this problem I found that tiles controllers don't throw exceptions in such a way that a handler can deal with them, and an informative way during development. But they are a nice

Re: common information in every view

2005-02-17 Thread Bill Schneider
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).

Re: common information in every view

2005-02-17 Thread Larry Meadors
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,

Re: common information in every view

2005-02-17 Thread Mark Lowe
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 <[EMAIL PROTECTED]> wrote: > Hello, > > I am building an application that will store menu options