On 12.4.12 19:05, Angela Schreiber wrote:


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* :)

We might want to change that agreed. I'm just not sure to what ATM. Return the added node or null if it already exists? Return the added node or the existing node if it already exists? Return the added node and throw if it already exists?


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.

Right. It's a low level interface. It is simple by design. The functionality you are missing should best go into some helper/convenience classes.

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?

Yes that was my intention. And it should be reflected by TransientNodeState and NodeStatedEditor, respectively.


[...] [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.

That's be great, thanks!

Michael


kind regards
angela

Reply via email to