Hi, On Wed, Apr 24, 2013 at 3:59 PM, Angela Schreiber <[email protected]> wrote: > as far as access control content is concerned that validation > is IMO required due to the fact that without the mixin type > on the parent the policy nodes would have a different declaring > node type which IMO is part of the contract defined by the > implementation... e.g. the repo could contain rep:policy nodes > that are basically invalid.
I'm proposing that we move the checking of such constraints to the type validator where we already have all relevant type information readily available and where we can more easily optimize the constraint checking. Note that doing so would require us to extend the type validator with some extra rules, like that content in reserved namespaces like rep/internal can only occur when there's a built-in node type with a matching named item definition. Such a rule would for example guarantee that a rep:policy node can only occur when the parent is rep:AccessControllable. Then there would be no need for the access control validator to re-check that constraint and it could simply treat all rep:policy nodes as containers of access control information. > while taking a closer look at the permission evaluation i found > that the commit hooks and validators get informed about all > index updates which then get explicitly ignored by most > validators/hooks, except for those dealing with index update. The best way to address this is to move the index updates to be performed only after all the other hooks/editors have been processed. Unfortunately this doesn't cover all possible cases (like when an entire subtree is copied around together with the contained hidden content), so an additional piece of functionality, described below, is needed. > wouldn't it be possible to make it an explicit characteristic > of the commit hooks if they want/need to deal with hidden > trees and/or properties? IMO that would simplify the wast > majority of all hooks and significantly reduce the amount of > calls. Indeed. The o.a.j.o.spi.commit.VisibleEditor wrapper class that's explicitly designed for this purpose. The provider of an editor (which is what most of our commit hooks would ideally become), that doesn't need to care about hidden content, can use a VisibleEditor wrapper for the root editor it returns to prevent any hidden content from showing up to that editor. See the TypeEditorProvider class for an example of that feature in action. BR, Jukka Zitting
