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:adam.gordon@(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:adam.gordon@(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: user-unsubscribe@(protected)
> For additional commands, e-mail: user-help@(protected)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@(protected)
> For additional commands, e-mail: user-help@(protected)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@(protected)
For additional commands, e-mail: user-help@(protected)
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@(protected)
For additional commands, e-mail: user-help@(protected)
