Adam, Yes indeed a controller is more suitable here.The TilesAction approach is useful when a radically different layout is required depending on a condition. rgds Rahul
-----Original Message----- From: Adam Gordon [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 12, 2006 5:44 PM To: Struts Users Mailing List Subject: Re: Struts Tiles question re menus Rahul- After reading 5.2.2, I can make it work using that structure, however I believe it defeats the original intent of Tiles because it would require me to have a n^2 tiles definitions for each scenario where n is the number of submenu items that need to be configured. After some digging around with your tiles controller idea and reading the relevant section in that PDF, I defined my own tiles controller for that module and can retrieve the list of menu items for any tiles definition. Then, I can iterate over the menu items and make invisible any menus that are not supposed to be shown. Here's the code: tiles XML: <definition name="foo" extends="bar" controllerClass="path.to.MyTilesController"> <putList name="subMenuItems"> <bean classtype="path.to.my.MenuItem"> <set-property property="prop1" value="val1"/> <set-property property="prop2" value="val2"/> <set-property property="menuItemVisibility" value="true"/> </bean> <bean classtype="path.to.my.MenuItem"> <set-property property="prop1" value="val1"/> <set-property property="prop2" value="val2"/> <set-property property="menuItemVisibility" value="true"/> </bean> <bean classtype="path.to.my.MenuItem"> <set-property property="prop1" value="val1"/> <set-property property="prop2" value="val2"/> <set-property property="menuItemVisibility" value="true"/> </bean> </putList> </definition> tiles controller JAVA: import org.apache.struts.tiles.Controller; // other imports... public class MyTilesController implements Controller { public void execute(ComponentContext tileContext, HttpServletRequest request, HttpServletResponse response, ServletContext servletContext) throws Exception { LOGGER.log(Level.FINE, "in tile controller execute method"); ArrayList<MenuItem> subMenuItemList = (ArrayList<MenuItem>)tileContext.getAttribute("subMenuItems"); if (subMenuItemList != null) { // do stuff here } } } Asthana, Rahul wrote: > Look at "5.2.2 One Controller - Multiple Views" > in http://www2.lifl.fr/~dumoulin/tiles/tilesAdvancedFeatures.pdf > This allows you to choose layouts on the fly. > This can also be done by using just an org.apache.struts.tiles.Controller. > > > -----Original Message----- > From: Adam Gordon [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 12, 2006 3:58 PM > To: Struts Users Mailing List > Subject: Struts Tiles question re menus > > > Hi- > > We're using Tiles to define submenu items (in a putList) for menu we > have in our web app. We're using a custom menu object that has a > visibility flag that we can toggle depending on whether or not the user > has permission to see a given menu functionality. > > My problem is that I can't seem to find a way (generic or otherwise) to > retrieve a handle to those menu objects to toggle the visibility after > the user logs in and the features that he/she are allowed to use are > activated. I thought about pulling them out of tiles all together, > however, I then lose the benefits of tiles and the placement of these > pages and would have to think about how to do this. > > The place we would do this is in a request listener class we have that > currently, amongst other things, creates the entire menu system for the > user. Basically, we iterate over all the modules constructing menus for > each one and then we place each menu in the appropriate section. But, > since the submenu items are created via Tiles, we don't have a handle to > the menu items... > > Any ideas? > > -adam > > --------------------------------------------------------------------- > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
