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-taglib (used to be portlets, etc.)
Date Thu, 17 Feb 2005 15:25:48 GMT
Hi david
  I uploaded a new version with a few more tags.
If you want to evaluate the tags download this version. The previous was 
uploaded in the middle of the development process.

Now the list includes:

jcr:session - Gets a session
jcr:cd - Sets the current working directory
jcr:nodes - Traverses the tree and iterates through the returned nodes
jcr:properties - Iterates through the node properties
jcr:set - Sets an attribute with the given jcr item
jcr:out - Displays an item through a template engine.
jcr:count - Displays the number of nodes for the given traverse strategy.
jcr:size - Displays the cum. size of nodes for the given traverse strategy.
jcr:versions - Traverses versions from the baseversion of the given node
jcr:query - Performs a query and iterates through the returned nodes
jcr:ifPresent - Processes the body if the jcr item exists.

Best regards

Edgar Poce wrote:
> Hi david
> David Nuescheler wrote:
>> hi edgar,
>>>> one thing that i thought of, was to introduce
>>>> something like a "current working directory" that
>>>> allows simple navigation in nodes.
>>>> something like:
>>>> <jcr:cd path="/level1/mytest">
>>>>  <jcr:out path="../bla/mynode" />
>>>>  <jcr:out path="/app:myprop" />
>>>> </jcr:cd>
>>> I like the idea and I'll add it ASAP. But I would rename the attribute
>>> "path" to "node" or "item" because an EL expression might be used
>>> instead of the path. eg. "${myNode}" instead of "/pathToMyNode/MyNode".
>> hmmm... well, i am a bit attached to the path for a number of
>> reasons. for one in many situations people actually have a path
>> "hardcoded in their jsp template" rather than the actual items.
>> also, i think it may be an intersting feature of <jcr:cd> to skip
>> the section to the </jcr:cd> in case the path does not exist.
> I like the feature. If "cd" behaves in that manner we should change 
> every tag in the set to ignore the body if the node doesn't exist. What 
> do you think of adding a conditional tag called "ifPresent"?.
> <jcr:ifPresent node="/myNode">
>   ... do some stuff
> </jcr:ifPresent>
>> can we settle for having both a "path" and a "node" or an "item"...  
>> what do you think?
> I wasn't clear, I meant that jcr:cd as all the tags in the set with a 
> node attribute should accept any of the following values:
> 1. EL expression. e.g. ${node}
> 2. Abstolute path. e.g. /pathToMyNode/myNode
> 3. Relative path. e.g. If not nested in a "cd" tag the path would be 
> relative to the root node.
> I thought that "node" was more descriptive, but if you still feel 
> atached to "path" I change it.
>>>> i think this could also provide for more modular
>>>> jsp includes...
>>>> what do you think?
>>> Yes, it could. But I guess that won't be the most common use case. With
>>> jsp includes the jsp pages would lose control of the current working
>>> directory. I think the JCR tags should store data by default only in the
>>> page context in order to keep control of the surrounding session and
>>> current working directory. If anyone wants to store an Item in the
>>> request, session or servletcontext it can be done through the core jstl.
>> i initially thought of storing the <jcr:cd> stack in a request attribute
>> and until now i couldn't come up with a reason why that should be bad.
>> additionally, it allows for the described jsp nesting which we use very
>> frequently to render content-repository-based components of a page.
>> is there a drawback of storing it that way?
> No, there's not, but in most cases I prefer to have a template with self 
> contained pieces as much as possible and thus facilitate reusability
> What do you think of following jstl and adding a "scope" attribute?. As 
> in jstl the default would be page context and it would accept the 
> following values: default, request, session, application.
>> regards,
>> david
> regards
> edgar

View raw message