Bertrand Delacretaz wrote:
On Jan 21, 2008 9:39 AM, Felix Meschberger <[EMAIL PROTECTED]> wrote:
...The better way is to do:
Session session =
request.getResourceResolver().adaptTo(Session.class);...
If the Resource is a JCR node, it would be convenient to have direct
access to a "session" variable, or "JcrSession" to avoid confusion
with the HTTP Session.
Currently these scripting variables are set in SlingScriptServlet:
SlingBindings props = new SlingBindings();
props.put(REQUEST, req);
props.put(RESPONSE, res);
props.put(FLUSH, TRUE);
To avoid hardcoding additional values here, maybe this could ask the
current Resource for more variables to bind? A JcrResource could then
provide the JCR session, workspace, queryManager or whatever's
convenient, in a way that's localized to the JcrResource's
JCR-specific code.
WDYT?
I think that making additional variables makes sense as it simplifies
writing scripts. But I don't think that this is the task of a resource.
For instance, if you have a non-jcr-resource this resource does not have
a jcr session, but still you might want to use a jcr session in your
script. But you don't want to care what kind of resource you have just
in order to get a jcr session.
So I think it's more the task of the resource resolver. Perhaps together
with the new adapter factory this can be made easily plugable/extensible?
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
