there was a long discussion on this. i first proposed what you propose, but later i changed my mind, but still am on the fence :)
the thing here is that isenabled() and isallowenabled() are orthogonal in the sense that one is meant to be implemented by the user and the other by the security policy. so if our isenabled() checks for isallowenabled() then anytime the user overrides it they have to remember to check for isallowenabled() - and if they forget they break security. on the other hand if the user is implementing a component that needs to properly handle the disabled state they have to do the check isEnabled()&&isAllowedEnabled() which also has a potential for breaking security - but as a component _implementor_ they should be a bit more aware. the first case happens a lot more often so we cater for that one. the perfect situation would be to have another hook for the user to implement, and have isenabled() as final that performs both checks. the problem is coming up with a good name for that new method. -Igor On 10/8/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
We have two methods that determine whether component should be allowed. Do we always check both? I mean, look at Link#onComponentTag, we only check isEnabled. So even though enable is not allowed, we still render link as enabled. Is this right? Shouldn't e.g. isEnabled() return false if the ENABLE action is not permitted? -Matej
