On 13.4.12 8:12, Angela Schreiber wrote:
hi
On a related note: what kind of values do we want to expose from
oak-core?
JSON like or JCR like?
I'd ideally like to keep it JSON-like so we can easily implement a
JavaScript-friendly HTTP mapping directly based on the Oak API without
having to go through extra levels of mapping.
Implementation wise, would that en/decoding happen inside oak-jcr or
oak-core?
I'd put the JSON-JCR type mapping into a shared helper class in
oak-core since it'll be needed by a lot of things like query and node
type handling inside oak-core. But the API interfaces should IMO be
based on JSON types to support cases where JCR typing isn't needed or
wanted.
having a mapping to JSON is required anyway. the basic question
for me is whether oak-api should use that natively. and in which
cases jcr typing wasn't needed/wanted.
based on my assumption that in our default use-case there is
no remoting between oak-jcr and oak-core i just see the drawback
of converting jcr-Value to json (oak-jcr) and parse it again
to build some sort of oak-Value that have all type information
for validation... instead of having that abstracted in an oak-Value
interface.
since we don't use qualified names, the jcr-value in most
cases was very similar to the oak-value.
having said that: thinking of a ValueFactory implementation
in oak-jcr that creates Value objects that can server both as
jcr-values and oak-values. the internal representation could
still be anything including json-representation... but we
wouldn't be limited to JSON types on the API level.
This sounds like an interesting idea. It kind of covers the middle
ground between both approaches. Only that I'd put that implementation
into oak-core, not into oak-jcr.
Michael
kind regards
angela
BR,
Jukka Zitting
