On 10/9/07, Edgar Poce <[EMAIL PROTECTED]> wrote: > > Hi, > > On 10/5/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > Hi, > > > > Am Montag, den 24.09.2007, 11:34 -0300 schrieb Edgar Poce: > > > Another doubt is what's the recommended practice to create a simple > > > sling component with write capabilities, how the component should > > > access the jcr repository to perform write operations? and how the jcr > > > session should be acquired? > > > > The nice thing about Sling is, that you do not have to write the data > > yourself by acquiring a session and calling all these JCR methods. You > > just take the Content you get from the request, update it using the > > Content's setter methods and call the ContentManager.store(Content) > > method. That is all. > > > > One of the nice things of JCR is that it can handle unstructured > content, it seems it won't be possible to use this feature from a > Sling component because it requires the content to be mapped in OCM.
Pojos can be mapped in unstructured structure like nt:unstructured. this is not mandatory to map a pojo to a strong jcr node types. That means you can deploy any kind of modules (called bundles I think:-) ) which have strong business rules and a nice content model without modifying the target repo. If needed 3rd party applications (or bundles) can still use the repo without knowing the content model. And if the JCR API is hidden behind the ContentManager then useful > operations such as versioning and locking wouldn't be accessible to a > Sling component. Versionning & lock are supported in the OCM framework. Personally I like the idea discussed in another > thread of using OCM optionally and give access to the JCR API from the > Sling API. I'm agree with you. it certainly to early to lock some way. Both solutions would be supported but I like to have "a minimum of abstraction" :-) br, Christophe
