Hi, > From: Jukka Zitting [mailto:jukka.zitt...@gmail.com] > On Thu, Nov 29, 2012 at 3:11 PM, Marcel Reutegger > <mreut...@adobe.com> 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,
hmm, I didn't consider that case. Is this really something we want to support? I don't think we had that feature in Jackrabbit. alternatively this can also be achieved by running an import on top of the MicroKernel or NodeStore API directly without any validators. > or explicitly modify a version history why would you want to do that? I think it is better to limit the possible modifications to what the spec allows you to do. > or a checked out node in ways that don't fit within > the mentioned predefined operations. there wouldn't be any restrictions in this case. you can do whatever you want with a checked out node. I probably missed something. Can you describe in more detail what you mean here? > 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. can you give an example? > 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. yes, that would also work. though, it requires you to use those classes on top of the oak-api when you want to provide remoting for version operations. with my approach one could simply perform content modifications on the oak api to trigger the version operations. regards marcel
