On 18.9.12 10:44, Jukka Zitting wrote:
Hi,
On Tue, Sep 18, 2012 at 11:40 AM, Michael Dürig <[email protected]> wrote:
I think we should unify the approach and extend it to other areas where
applicable. The advantages are that there is no code duplication for
functionality required in oak-jcr and oak-core and that these classes can be
instantiated ad hoc without the need for passing instances of these around.
+1 This approach already opened up a chance to simplify some of the
name validation code in .oak.plugins.name (no need for the extra
Namespaces utility class), on which I'm just now working.
Taking this further, the alignment could probably also be extended to
AbstractNameMapper, which follows a similar pattern. Currently there is
only one implementation, which is 'session based'. Providing an
implementation based on a read tree, NameMapper and NamePathMapper
instances could also be used from within oak-core.
Even further this decouples ValueImple, ValueFactoryImpl and related
from the session. So we could move these also to oak-core. Now while we
are at it, is there then still a reason for having a CoreValue
implementations and ValueImpl? Why not just make CoreValue extend
javax.jcr.Value?
BTW: javax.jcr.Value is indeed required in oak-core for checking value
constraints on node types. Currently this is solved by introducing (yet
another) value implementation: JcrValue implements javax.jcr.Value which
we could get rid off at the same time also.
Thoughts?
Michael
