jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edgar Poce <edgarp...@gmail.com>
Subject Re: JCR, Portlets and usecases
Date Mon, 14 Feb 2005 07:37:39 GMT

  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 

Any feedback is welcome.


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

View raw message