On 11/25/05, Ryan Wynn <[EMAIL PROTECTED]> wrote: > > I was doing some work on enabling declarative component level render > permissions alongside shale-clay. What I came up with was to use the > postProcessCreateComponent pluggable command in clay's chain. In this > command I check the current component for an attribute called > 'renderIfRoleIn'. This attribute is designed to be a comma delimited > list of user roles. I then check if the user's role is in this list > using request.isUserInRole(nextRole); if not I set the rendered > property of the component to false. > > I was thinking this might be something that could be useful at a shale > or clay level. If not at that level then maybe a shale-xxx.jar > plugin. Any thoughts? > > Ryan
Interesting idea ... but I wonder if we are trying to bury too much logic in the view tier with this approach? I'm just thinking that the next person who comes along will say "it's not just user roles that matter for me, it's whether the user is the manager of a particular department whose detailed information I'm about to display" -- a concept that I would not assume is represented as an explicit role (in terms of container managed security constraints). Wouldn't it be more general to just bind the rendered property of the component to a boolean function in your backing bean, which did the appropriate calculations? One could certainly write some simple utility functions that did lookups based on arbitrary sets of roles (which would have to be encoded into the component somehow), or perhaps better would be a set of predefined methods for all the interesting combinations (isManager(), isUser(), isLoggedOn(), ...). The implementations of these methods can implement whatever state checking is relevant, which may include roles but may also include checking other information -- and these sorts of nitty gritty details are not something the page author should have to be worried about. Craig
