Hi Juergen, How do you get the component path ? I guess you talk about org.apache.wicket.authorization.IAuthorizationStrategy#isInstantiationAuthorized(Class) which receives a Class as parameter, not a Component. So I don't see how you get the component path from that class. If you are able to get the component path then you should be able to do:
component.findParent(ListPanel1.class) != null. This is possible for org.apache.wicket.authorization.IAuthorizationStrategy#isActionAuthorized(Component, Action) I'm not sure why IAuthorizationStrategy#isInstantiationAuthorized() accepts a Class as parameter while even the component is available: https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/Application.java#L280 On Sat, Apr 21, 2012 at 10:51 AM, Jürgen Lind <[email protected]> wrote: > Hi, > > I am looking for ideas on how to implement a context-aware > AuthorizationStrategy. > This means that I need a way to decided whether a certain self-written > component can > be instantiated in a particular context or not. For example, the "filter" > component > may be show to a user with a certain permission when looking at ListPanel1, > but not > when looking at ListPanel2. > > In previous Wicket applications, a have use my own annotation-based scheme > that worked > very well, but I cannot use it for this application since the permission > granularity is > much more fine-grained and context sensitive. > > Is there any good way of doing this? I already tried looking at the > component path, but > that does not give me the information I need since it only covers the ids of > the > components i.e. using the above "filter" component in a setting where > ListPanel1 and > ListPanel2 are switched via Ajax calls, I get the same component path... > > Thanks for any ideas, > > J. > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
