On 13.4.12 16:20, Michael Dürig wrote:
On 13.4.12 13:29, Angela Schreiber wrote:
[...]
- if we made TransientNodeState the main node-like interface
on the oak-api that is really distinct from the NodeState
concept in mk and the core impl, i would like to suggest to
move the (few) modifier methods to that interface.
for the sake of an API that is easy to read and easy to use.
- The editor was then not used to edit states but could be e.g.
renamed to ChangeSet|Log (or similar). it's single
purpose was then to collect the changes.
See my introduction for why this is so. I think it makes sense to keep
these apart on the API level. But I'm in favour to implement something
on top of these interface which looks like a node which can directly be
modified.
On a related note I saw that NodeImpl.getEditor() changed from private
to public in order to be accessible from the user management
implementation. We should revert that later on. Otherwise we end up with
client casting Node to NodeImpl and accessing internals they shouldn't.
My suggestion is to implement a node-like class on top of
TransientNodeState and NodeStateEditor (see above) which covers all that
internal functionality (like setting internal/protected items etc.) We
then should internally pass instances of this class around and adapt it
to javax.jcr.Node for external JCR clients. WDYT?
Michael
