Hi, On Thu, Nov 29, 2012 at 3:11 PM, Marcel Reutegger <[email protected]> wrote: > now, to implement the various JCR versioning operations, I'd like > to encapsulate them in commit hooks as much as possible. this > avoid the need to duplicate code and perform consistency checks > in various places. my idea is to trigger those hooks with a defined > set of content modification on Trees on through the oak API:
This might be troublesome in some cases, for example if we want to import a node together with its version history, or explicitly modify a version history or a checked out node in ways that don't fit within the mentioned predefined operations. I wouldn't want to run into cases where a client can't do something it wants because doing so would trigger unwanted content modifications by the commit hooks. I'd rather just have a Validator that ensures that whatever you do, the version history and related bits are internally consistent and conform with whatever other constraints we have (location/structure of version histories, etc.). For example, when making a node versionable, already the mix:versionable node type requires the presence of relevant versioning properties, and the versioning validator could simply make sure that those properties point to existing and valid version history information. As for the code duplication argument, I'd take care of that simply by making the relevant code available as a reusable set of classes. See for example how the namespace and node type management code is handled. BR, Jukka Zitting
