Re: common information in every view
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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: common information in every view
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: common information in every view
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). How often do the menu options change in practice? You might find that they never actually change in your production environment, in which case just shoving them in application scope is often sufficient. For the design pattern in general, you could consider using Tiles and a Tiles controller, rather than using a base action class. This would give you greater separation of concerns: loading (possibly cached) menu items is handled specifically by the tile that displays the menu, rather than by each individual action. -- Bill -- Bill Schneider Chief Architect Vecna Technologies 5004 Lehigh Rd., Suite B College Park, MD 20740 [EMAIL PROTECTED] t: 301-864-7253 x1140 f: 301-699-3180 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: common information in every view
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 option. 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). You can repopulate the data whenever you like and from a struts action if you wish, the same way you would with httpsession or request. Mark On Thu, 17 Feb 2005 10:25:04 -0500, Bill Schneider [EMAIL PROTECTED] wrote: 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). How often do the menu options change in practice? You might find that they never actually change in your production environment, in which case just shoving them in application scope is often sufficient. For the design pattern in general, you could consider using Tiles and a Tiles controller, rather than using a base action class. This would give you greater separation of concerns: loading (possibly cached) menu items is handled specifically by the tile that displays the menu, rather than by each individual action. -- Bill -- Bill Schneider Chief Architect Vecna Technologies 5004 Lehigh Rd., Suite B College Park, MD 20740 [EMAIL PROTECTED] t: 301-864-7253 x1140 f: 301-699-3180 - 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]
Re: common information in every view
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 Lowe [EMAIL PROTECTED] wrote: 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 option. 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). You can repopulate the data whenever you like and from a struts action if you wish, the same way you would with httpsession or request. Mark On Thu, 17 Feb 2005 10:25:04 -0500, Bill Schneider [EMAIL PROTECTED] wrote: 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). How often do the menu options change in practice? You might find that they never actually change in your production environment, in which case just shoving them in application scope is often sufficient. For the design pattern in general, you could consider using Tiles and a Tiles controller, rather than using a base action class. This would give you greater separation of concerns: loading (possibly cached) menu items is handled specifically by the tile that displays the menu, rather than by each individual action. -- Bill -- Bill Schneider Chief Architect Vecna Technologies 5004 Lehigh Rd., Suite B College Park, MD 20740 [EMAIL PROTECTED] t: 301-864-7253 x1140 f: 301-699-3180 - 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]
