jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Different types of 'item modification' on oak-jcr (and oak-api)
Date Thu, 12 Apr 2012 18:05:15 GMT
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

Mime
View raw message