You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Rickard Öberg <ri...@senselogic.se> on 2005/02/13 07:02:28 UTC
JCR, Portlets and usecases
Hi!
Now that the PFD is out I want to air some thoughts about how JCR could
work together with Portlets.
My background is that I have a CMS/portal implementing JSR168, and our
partners are "screaming" (figuratively speaking) for a way to access our
internal page structure and render it. This is where JCR would come in
quite nicely.
Accessing the Repository from a portlet would be quite natural (simply
look it up in the "java:comp/env" JNDI context), but I'm unsure how
common usecases would be dealt with most efficiently.
Here is a common one just to describe the basic problem:
A portlet wants to render a menu describing the site structure. I would
prefer if this is done by using the XML export feature in combination
with an XSL transformation in the portlet. That way it is easy to tweak
the actual HTML generation. But, since such a usecase is only interested
in a small subset of data (e.g. path+displayname+UUID for one sublevel
of the current node) the current XML export feature is too
coarse-grained. It's an "all-or-nothing" approach. In terms of the
current JCR API it would probably be more efficient to implement an
ItemVisitor which exports a specific subset of the model to SAX. Such an
ItemVisitor could probably be made totally generic, if one wants to.
With a SAX-exporter that can be tweaked for various usecases it should
be very easy and efficient to implement a number of common JCR+Portlet
usecases.
So here are my actual questions:
* Is anyone else going to use JCR in the context of portlets?
* If yes, how do you see it being used, commonly? As above, with
XML(SAX)+XSL, or in some other way?
* Are there any tools, like the SAX-exporter outlined above, which
could/should be made available within the Jackrabbit context?
Any other general thoughts related to JCR and Portlets would also be
most welcome :-)
regards,
Rickard
Re: JCR, Portlets and usecases
Posted by Edgar Poce <ed...@gmail.com>.
Hi
I'm working on a set of tags that reads and displays jcr data. You can
plug your custom traverse strategy and template engine, so I guess it
fits your needs as long as you use jsp instead of xml/xsl for rendering
your portlets.
The maven generated site is deployed at
http://cablemodem.fibertel.com.ar/edgarpoce/
Any feedback is welcome.
Edgar
Rickard Öberg wrote:
> Stefan Guggisberg wrote:
>
>> take a look at javax.jcr.util.TraversingItemVisitor. by extending from
>> TraversingItemVisitor.Default you can selectively override any
>> of the entering/leaving methods.
>
>
> Right, but then it will traverse the entire model, right? For most cases
> I want a really small subset of the data, so traversing the whole model
> isn't very nice.
>
>> btw: alternatively you could very easily write your own ContentHandler
>> that filters out any unwanted content and pass that ContentHandler to
>> the standard JCR export methods in the Session interface.
>
>
> Sure, but it would have the same problem as with the above: it would in
> many cases be some "Yes, I want this" and in most "No, I don't want
> this". Not very performant.
>
> Anyway, I hacked together a Level-1 repository implementation this
> weekend and jacked it into our Java object model, and wrote a test
> portlet that renders a simple menu. Works great!
>
> I tied the repository to "java:comp/env/jcr/repository". Does anyone
> have better ideas? Also, would it make sense to tie "The current
> page/node" to the JNDI context and/or portlet attributes when rendering
> a portlet page? If so, under what name(s)? There's all sorts of best
> practice issues here I think.
>
> I have a couple of problems with the design of the API (I have no idea
> why the meth. names are abbr.), but overall it works reasonably well for
> what it's supposed to do. It is infinitely better than having people tie
> their code to our internal interfaces :-)
>
> /Rickard
>
>
Re: JCR, Portlets and usecases
Posted by Rickard Öberg <ri...@senselogic.se>.
Stefan Guggisberg wrote:
> take a look at javax.jcr.util.TraversingItemVisitor. by extending from
> TraversingItemVisitor.Default you can selectively override any
> of the entering/leaving methods.
Right, but then it will traverse the entire model, right? For most cases
I want a really small subset of the data, so traversing the whole model
isn't very nice.
> btw: alternatively you could very easily write your own ContentHandler that
> filters out any unwanted content and pass that ContentHandler to the
> standard JCR export methods in the Session interface.
Sure, but it would have the same problem as with the above: it would in
many cases be some "Yes, I want this" and in most "No, I don't want
this". Not very performant.
Anyway, I hacked together a Level-1 repository implementation this
weekend and jacked it into our Java object model, and wrote a test
portlet that renders a simple menu. Works great!
I tied the repository to "java:comp/env/jcr/repository". Does anyone
have better ideas? Also, would it make sense to tie "The current
page/node" to the JNDI context and/or portlet attributes when rendering
a portlet page? If so, under what name(s)? There's all sorts of best
practice issues here I think.
I have a couple of problems with the design of the API (I have no idea
why the meth. names are abbr.), but overall it works reasonably well for
what it's supposed to do. It is infinitely better than having people tie
their code to our internal interfaces :-)
/Rickard
Re: JCR, Portlets and usecases
Posted by Stefan Guggisberg <st...@gmail.com>.
On Sun, 13 Feb 2005 07:02:28 +0100, Rickard Öberg
<ri...@senselogic.se> wrote:
> Hi!
>
> Now that the PFD is out I want to air some thoughts about how JCR could
> work together with Portlets.
>
> My background is that I have a CMS/portal implementing JSR168, and our
> partners are "screaming" (figuratively speaking) for a way to access our
> internal page structure and render it. This is where JCR would come in
> quite nicely.
>
> Accessing the Repository from a portlet would be quite natural (simply
> look it up in the "java:comp/env" JNDI context), but I'm unsure how
> common usecases would be dealt with most efficiently.
>
> Here is a common one just to describe the basic problem:
> A portlet wants to render a menu describing the site structure. I would
> prefer if this is done by using the XML export feature in combination
> with an XSL transformation in the portlet. That way it is easy to tweak
> the actual HTML generation. But, since such a usecase is only interested
> in a small subset of data (e.g. path+displayname+UUID for one sublevel
> of the current node) the current XML export feature is too
> coarse-grained. It's an "all-or-nothing" approach. In terms of the
> current JCR API it would probably be more efficient to implement an
> ItemVisitor which exports a specific subset of the model to SAX.
take a look at javax.jcr.util.TraversingItemVisitor. by extending from
TraversingItemVisitor.Default you can selectively override any
of the entering/leaving methods.
btw: alternatively you could very easily write your own ContentHandler that
filters out any unwanted content and pass that ContentHandler to the
standard JCR export methods in the Session interface.
cheers
stefan
> Such an ItemVisitor could probably be made totally generic, if one wants to.
> With a SAX-exporter that can be tweaked for various usecases it should
> be very easy and efficient to implement a number of common JCR+Portlet
> usecases.
>
> So here are my actual questions:
> * Is anyone else going to use JCR in the context of portlets?
> * If yes, how do you see it being used, commonly? As above, with
> XML(SAX)+XSL, or in some other way?
> * Are there any tools, like the SAX-exporter outlined above, which
> could/should be made available within the Jackrabbit context?
>
> Any other general thoughts related to JCR and Portlets would also be
> most welcome :-)
>
> regards,
> Rickard
>
Re: JCR, Portlets and usecases
Posted by Jukka Zitting <ju...@zitting.name>.
Hi,
Rickard Öberg about the jcr-ext XML tools:
> That sounds just about right :-) Great!
I've now cleaned up and tested my document view exporter class. I've
also implemented the latest functionality defined in the PFD spec
(jcr:xmltext, name escaping, multi-values, etc.) and added two hook
methods called includeProperty() and includeNode() that can be used by
subclasses to select which nodes and properties should be included in
the XML serialization. The class should also be pretty well documented.
For quick access, please see
http://yukatan.fi/2005/02/DocumentViewExportVisitor.java or my private
svn repository. I'll soon send another message about including the XML
tools directly in the Jackrabbit source tree.
Best regards,
Jukka Zitting
Re: JCR, Portlets and usecases
Posted by Rickard Öberg <ri...@senselogic.se>.
Jukka Zitting wrote:
>>* Are there any tools, like the SAX-exporter outlined above, which
>>could/should be made available within the Jackrabbit context?
>
> I'm working on a general set of XML import/export tools for JCR. (See
> the earlier thread on my contrib/jcr-ext proposal.) One part of the
> toolset is an XML export visitor that uses only the public JCR API. It
> would probably be easy to subclass the general export visitor to suit
> your needs. I'll see if I could add some utility hooks to make the task
> even easier.
That sounds just about right :-) Great!
/Rickard
Re: JCR, Portlets and usecases
Posted by Jukka Zitting <ju...@zitting.name>.
Hi Rickard,
Rickard Öberg wrote:
> * Are there any tools, like the SAX-exporter outlined above, which
> could/should be made available within the Jackrabbit context?
I'm working on a general set of XML import/export tools for JCR. (See
the earlier thread on my contrib/jcr-ext proposal.) One part of the
toolset is an XML export visitor that uses only the public JCR API. It
would probably be easy to subclass the general export visitor to suit
your needs. I'll see if I could add some utility hooks to make the task
even easier.
An early version (alpha quality!) of my XML export classes is available
in svn://svn.yukatan.fi/public/yukatan/trunk/jcr-ext, but my current
plan is to migrate the classes to the main Jackrabbit source tree.
There's however some policy and API stability issues to work out before
I can commit the classes. You may also want to check out the internal
XML exporter classes in org.apache.jackrabbit.core.xml.
Best regards,
Jukka Zitting