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
