jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: Oak-API - some comments and suggestions [1]
Date Fri, 13 Apr 2012 17:27:39 GMT


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

Mime
View raw message