Re: Components Writing Content (was: how to build sling components with complex user interaction and write capabilities?)

[Edgar Poce <ed...@gmail.com>]

Hi,

On 10/5/07, Felix Meschberger <fm...@gmail.com> 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.
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. Personally I like the idea discussed in another
thread of using OCM optionally and give access to the JCR API from the
Sling API.

br,
edgar

> For example: Consider you have a TextComponent and a TextContent, where
> the TextContent has a title and a text field. In your
> TextComponent.service() method you might do the following:
>
>         if ("POST".equalsIgnoreCase(request.getMethod())) {
>           TextContext textContent = (TextContent) request.getContent();
>           textContent.setTitle(request.getParameter("title"));
>           textContent.setText(request.getParameter("text"));
>
>           ContentManager contentManager = (ContentManager) request.getAttribute(org.apache.sling.core.Constants.ATTR_CONTENT_MANAGER);
>           contentManager.store(textContent);
>           contentManager.save();
>         }
>
> This is more or less the idea. If you look at the
> org.apache.sling.core.components.DefaultComponent you will see more
> elaborate code showing this intention.
>
> To create content, you would just instantiate your Content object, set
> the properties and call the ContentManager.create(String path, Content
> content) (currently missing, see SLING-44 [1]) to store the content at
> the given path.
>
> Hope this helps.
>
> Regards
> Felix
>
> [1] https://issues.apache.org/jira/browse/SLING-44
>
>

Re: Components Writing Content (was: how to build sling components with complex user interaction and write capabilities?)

[Christophe Lombart <ch...@gmail.com>]

On 10/9/07, Edgar Poce <ed...@gmail.com> wrote:
>
> Hi,
>
> On 10/5/07, Felix Meschberger <fm...@gmail.com> 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