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: >>> >>> >>> >>> >> >>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 to skip > the section to the 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"?. ... do some stuff > 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 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