[
https://issues.apache.org/jira/browse/OAK-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated OAK-673:
--------------------------------
Attachment: OAK-673-VersionHook.patch
bq. Note that going forward I'd like to leverage the existing detailed type
information we have in the TypeEditor to allow type-specific code like the one
in VersionHook to be invoked by the TypeEditor whenever nodes of given types
are being modified. In other words, the TypeEditor would have it's own
extension point to which type-specific editors could be plugged in instead of
each of them having to separately look at all changes as reported by the
EditorHook.
I think that will have to be sooner rather than later.
See attached patch with the VersionHook change.
While the refactoring went smooth, the problem is the changes contributed by
this Editor are not seen by the others down the line (from the composite
editor).
So if we effectively add it to the existing list of editors (the composite) the
type validation will fail.
The patch currently adds the Editor as a single hook inside an EditorHook which
kinda defeats the purpose of this while exercise.
So I would push the patch in to have the VersionHook working as an Editor and
then start work on refactoring the TypeEditor so that it acts like a composite
Editor but also pushes changes from on to the other, finishing with an overall
type validation.
thoughts?
> Unified hook processing
> -----------------------
>
> Key: OAK-673
> URL: https://issues.apache.org/jira/browse/OAK-673
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
> Reporter: Jukka Zitting
> Assignee: Jukka Zitting
> Attachments: OAK-673-VersionHook.patch
>
>
> As [discussed|http://markmail.org/message/xqw3yg3z5rnsiwz3] on oak-dev@, it
> would be good reduce the number of separate content diffs that various hooks
> do during each commit. To do this without having to merge unrelated
> functionality into one big hook class we should come up with a new hook
> generalization, like the one I
> [proposed|http://markmail.org/message/bydje7rf3si67fc3], that allows multiple
> independent components to process the results of a single content diff.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
