Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of christophe.lombart@gmail.com
 designates 209.85.218.214 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=LC0Fvng2gJAKTRPcVsKbrdHg7WW7OTeFANu5RiVMVhQqw/xsIwClwAJ6nzls/CK6I0
         I7vnG748Adr/Nobp3p7GoP+uLbhLnhWGCPYsFP/ytVFGmnIHYCD3iw4hch/dFvl/4RQ+
         RFpG6PycR0a7lbOL68v38/xfQ0IsKm4z0W0W4=
MIME-Version: 1.0
In-Reply-To: <A60CA838-8A37-4E56-9E11-F9DC90AD6368@ecyrd.com>
References: <AA62724B-616D-4243-B867-6651D33B19F1@maya-systems.com>
	<ffd6aaa90911131421k412ddf94w1bfbe5521a05030f@mail.gmail.com>
	<14DC517E-115E-41D3-AC12-5D6AB1069CFB@maya-systems.com>
 <e2a35cbc0911140235r718dcab9h4ef6449df548cf4e@mail.gmail.com>
	<ebe4645f0911151514p38a60307q6837ae2902104141@mail.gmail.com>
	<c3ac3bad0911160438w55c28098webf97aff82f69751@mail.gmail.com>
	<4B029BFE.1070504@gmx.de> <A60CA838-8A37-4E56-9E11-F9DC90AD6368@ecyrd.com>
From: Christophe Lombart <christophe.lombart@gmail.com>
Date: Wed, 18 Nov 2009 13:53:26 +0100
Message-ID: <3b728ee90911180453m20f151d0oc3d10313bd7ad397@mail.gmail.com>
Subject: Re: David's Model question : nt:unstructured and SNS
To: users@jackrabbit.apache.org
Content-Type: multipart/alternative; boundary=000e0cdf9862b693620478a4bb46

--000e0cdf9862b693620478a4bb46
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Nice Discussion !

After making different projects based on Jackrabbit & OCM, my opinion is
changing (don't blame me, I'm one of the committer of the Jackrabbit OCM
 !). I came from the ORM technologies for building applications with many
layers. The more layers we had, the better it was. But now, my opinion is
changing because we are building content applications in a different way .
Indeed, there are new concepts & new technologies that can help us to have =
a
simpler architecture (aka OSGI, REST & JCR or "Sling ;-)"). With all of
that, OCM is not mandatory. I know, it is a long debate but I'm very
surprising on how we have simplified the code for a customer application,
just by using Sling (without speaking about the dev time). Read more on
[1].

Concerning OCM, I'm changing my opinion because (in a random order)  :
- JCR code on server side is very fast. Adding more layers & mapping will
decrease the performance and add complexity in the architecture.
- The server codes are generally smalls. So, using the JCR API is not a
problem (even if JCR code is more verbose).
- JCR is a standard, OCM is not. OCM has to reimplement all JCR features in
another/non standard API.
- JCR spec is simple to learn for a developer (no annotations, no mapping).
The model is simple : Items, Nodes, Properties for everything. JCR code can
be more generic.
- Changing the content model is easier with JCR than with OCM. Difficulties
to follow : "data first, structure later" with OCM.


Again, don't blame me but I think OCM was not a good idea. Make a try with
Sling and you will see how the JCR code can be simple.


[1] Just for the fun  :
http://www.slideshare.net/lars3loff/the-zero-bullshit-architecture (sorry
for the "free marketing" but it is so true)

2009/11/17 Janne Jalkanen <janne.jalkanen@ecyrd.com>

>
> On 17 Nov 2009, at 14:50, Sandro Boehme wrote:
>
> > Alexander Klimetschek schrieb:
> >> 2009/11/16 Fabi=E1n Mandelbaum <fmandelbaum@gmail.com>:
> >>> It's simpler than fiddling around with this low-level stuff actually:
> >>>
> >>> Just create a DAO to abstract all JCR operations (as you should be
> >>> doing already)
> >> (To give my usual opinion about object content mapping and JCR:) If
> >> you use DAOs this of course is a straight-forward solution (but only
> >> for the code that uses the DAO layer), but I think that using JCR
> >> directly is not "low-level" stuff:
> > In my opinion an OCM adds statical type checking and the ability to add
> functionality (e.g. finder methods) to this types.
>
> JSPWiki uses a layer on top of JCR to
> a) provide type/range checking for some values, and
> b) to provide backwards API compatibility.
>
> /Janne
>

--000e0cdf9862b693620478a4bb46--