|
|
|
[
Permlink
| « Hide
]
Darby Felton - 26/Jul/07 11:55 AM
Postponing to after 1.0.1.
But why is this a problem? The rule is satisfied by the Child role and since there is no ACL specifically for Parents on the Toy then Zend_Acl returns true.
Wouldn't performance suffer if Zend_Acl iterates through the whole inheritance only to come to the same conclusion that it did in the first place? Or do you see a use case where a custom Assertion will need to query this hierarchy to supply a more qualitative answer? Hey Simon,
The problem i specifically notice (from above) is in test case number 3. If I am writing custom assertions, then my assertion (if applied) should always get the exact object that i proposed when i asked if it "isAllowed". // IF I DO: $acl->isAllowed($mommy, 'Toy', 'Play'); // where mommy is of type (class Acl_Parent) I should expect any assertions that were triggered as a result of that exact query should indeed get teh exact object i passed into the query. The reason for that expectation is in case I want to call some Acl_Parent specific methods in order to assert that what is queried should be allowed or not. I see no direct performance impact, its simply a matter of whats being passed to the assertion. as far as this statement: > Or do you see a use case where a custom Assertion will need to query this hierarchy to supply a more qualitative answer? Assertions don't query the inheritance chain, its actually the other way around, currently the inheritance chain is iterated in order to trigger the appropriate assertion. make sense? This is still not fixed in 1.5.2, and is still quite irritating when trying to write any non-trivial assertions.
One workaround: (It's a good idea to make sure getLastRequest() always returns objects, even if a string was passed to isAllowed().) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||