On 11/25/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > 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 > >
Yeah, I agree with you Craig, it will invevitably become more complex. I just thought that a good percentage of the cases with be based simply on explicit roles. For these more complex cases it might be nice to be able to plug into an existing chain that is designated for this rendering purpose. For example the default behavior of the chain is to keep the rendered property as-is. But if the user plugs in a chain at a specific entry point then rendered could be overriden. For example in your scenario, it might be nice to be able to 'chainize' in commands the isManager, isManagerOfDepartmentX, isViewingDataX requirments. Only to benefit from the separation of concerns that chain offers. I guess from the framework point of view I would be asking to consider an entry point. Thanks, Ryan
