Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of anchela@adobe.com designates
 64.18.1.27 as permitted sender)
Message-ID: <4F87195B.6080409@adobe.com>
Date: Thu, 12 Apr 2012 20:05:15 +0200
From: Angela Schreiber <anchela@adobe.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
 rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: <oak-dev@jackrabbit.apache.org>
Subject: Re: Different types of 'item modification' on oak-jcr (and oak-api)
References: <4F85A60E.3020709@adobe.com> <4F85B19C.5030601@apache.org>
 <4F8688B1.5050206@adobe.com> <4F869CC0.8030907@apache.org>
 <4F86C6F7.20601@adobe.com> <4F86E0C7.7060901@apache.org>
 <4F86F8D9.6010007@apache.org> <4F87071C.2010205@adobe.com>
 <4F871254.8070904@apache.org>
In-Reply-To: <4F871254.8070904@apache.org>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

hi michael

>> what i am actually looking for (and had a quick discussion looking
>> at my real privilege-registration example) was probably some sort
>> of changelog/changeset and second some way of adding state
>> modifications independent from accessing jcr items.
>
> That's exactly what my proposal tries to solve. You would use the
> "system node editor" for that.

ok, than maybe i was just confused by the name :)

>> example: registering a new privilege could for example consist of
>>
>> - add a new node state underneath the dedicated priv-root
>> - add 2 properties to that new node state
>> - maybe there was even an additional next-level child node states.
>>
>> currently, i simply didn't find how i was able to do that
>> in a reasonable (simple) way and whether that really would
>> do, what i wanted it to do.
>
> editor.addNode("priv-root")

but that one already exists... i don't want to add it. but
re-reading the docu: "does nothing if it exists..." *arrrrrgh* :)

> privRootEditor = editor.edit("priv-root")

well. but if it was at a lower level i had to call 'addNode'
for every single level? and also call 'edit' for every single
level? ohno...

i neither want to add nor to edit at those - lets say -
5 top-levels until i reach my target node... here the
methods-names simple not represent what i want to do.
... if there was getNodeStateEditor(String path) i just
had that in one single method call... just an example.

>> 1) tried to use your workspace.copy example.... but
>> to connection.getNodeStateEditor i can't pass
>> a path but only a state other than the root node
>> that i simply don't have access to if i don't want to
>> use the current session.....
>> the currentroot was not the right location to add content.
>> ->  see also my comment on NodeStateEditor#edit below
>
> TransientNodeState.getChildNode()

but i don't want to have the transient state of the root
nor any other sublevel that i would want to bypass in order
to get to my target node... they can happily stay untouched.

and if i can commit any editor not only the root i don't
know why i had to do all the effort described above. i really
try to be very lazy ;)

>>
>> 2) i find it odd that NodeStateEditor#addNode doesn't
>> return me the new node state.

> That's easy to change and we probably should.

cool.

>> 3) the only way i found to add a next level to that new node state
>> was NodeStateEditor#edit(String)... was that assumption correct?
>> if it was i would find that API really troublesome and it looks
>> like a mixture of different concepts....
>
> Which concepts does it mix? It actually separates representation of
> state from modification of state.

yes... from the current aspect of the interfaces i just got
the impression that they are not natural to use which imo
usually evolves when mixing different things: a simple editor
for one node that does nothing else mixed up with some sort
of state-manager functionality... that was my impression.

so maybe we want to separate state-access-management from
changelog|set recording functionality... what do you think?

[...] [skipped explanations] (thanks! i really didn't get it
from looking at the interfaces...)

> Well there are no other proposals so far. So this API is still the best
> we have...

see above. with your explanations at hand i will take a closer
look at it again tomorrow... maybe i can come up with some
suggestions.

kind regards
angela