Hi, Am Montag, den 21.01.2008, 09:58 +0100 schrieb Bertrand Delacretaz: > 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);
There are more: OUT is the same as response.getWriter() and RESOURCE is the same request.getResource() and SLING is the SlingScriptHelper object. > > 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? -1, let me explain: JcrNodeResource (as is JcrPropertyResource) are private classes to the jcr/resource project. So there is no way of exposing special methods. In fact, this would not be nice as there would be a need for cast. To still be able to provide special "views" of the Resource (as well as the ResourceResovler and even more in the future, see the other thread on the "Everything is a Resource" concept), we introduced the adaptTo() method. The intent is to provide other views of the object. Having this in mind, retrieving the session from the Resource is not appropriate. For this reason, the Session is available from the ResourceResolver's adaptTo method. The workspace need not be provided, as this is accessible from the session. The queryManager is special and respective simplified API is available from the ResourceResolver in terms of the findResources and queryResources method. Regards Felix
