Hi,
On Wed, Feb 27, 2013 at 11:25 AM, Michael Dürig <mdue...@apache.org> wrote:
> Right but it might make sense to factor out an API based on these hooks that
> frees index implementations of having to worry which hook to use.
Indeed. Here's my initial draft of what this could look like:
interface EditorProvider {
Editor getRootEditor(
NodeState before, NodeState after, NodeBuilder builder);
}
interface Editor {
void propertyAdded(PropertyState after)
throws CommitFailedException;
void propertyChanged(PropertyState before, PropertyState after)
throws CommitFailedException;
void propertyDeleted(PropertyState before)
throws CommitFailedException;
Editor childNodeAdded(String name, NodeState after)
throws CommitFailedException;
Editor childNodeChanged(
String name, NodeState before, NodeState after)
throws CommitFailedException;
Editor childNodeDeleted(String name, NodeState before)
throws CommitFailedException;
}
Basically an Editor would be like a Validator except for the
difference that it can record changes to the content tree through the
given NodeBuilder instance.
The super hook would do a content diff and call each Editor in
sequence for all changes. If none of the Editors threw a
CommitFailedException before the whole diff got processed, the hook
would get the updated node state from the builder and use it to
complete the commit.
An observer that also wants to update the content tree could do the
same thing, passing the detected content changes to the configured
Editors and making a new commit of the resulting new node state if
none of the Editors failed with an exception.
BR,
Jukka Zitting
