You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Felix Meschberger (JIRA)" <ji...@apache.org> on 2008/02/15 09:11:08 UTC

[jira] Created: (SLING-247) Provide Scripting variables as request attributes for JSP

Provide Scripting variables as request attributes for JSP
---------------------------------------------------------

                 Key: SLING-247
                 URL: https://issues.apache.org/jira/browse/SLING-247
             Project: Sling
          Issue Type: Improvement
          Components: JSP
            Reporter: Felix Meschberger
             Fix For: 2.0.0


The scripting variables defined in the SlingBIndings class are defined as global variables in script language bindings such as JavaScript and Velocity. In JSP this binding does not exist yet.

The issue with JSP is, that JSPs are translated using a text-transformation to a Java class implementing the Servlet interface. As such there is no such thing as a global variable. A workaround to inject well known objects is implemented with <sling:defineObjects> tag. But this tag does not make the same defined variables available.

I suggest to enhance JSP scripting as follows:

(1) Bindings as Request Attributes
All bindings defined in the SlingBindings object prepared for the script evaluation are stored as request attributes for use by the JSP.

(2) Predefined bindings as variables through <sling:defineObjects>
Some of the predefined bindings in the SlingBIndings object are mapped as variables in the JSP when using the <sling:defineObjects> tag. Some variable require special treatment:
- request: The request variable already exists and is of type HttpServletRequest, the SlingHttpServletRequest object is bound as the slingRequest variable.
- response: Same as for the request. The SlingHttpServletResponse object is bound as slingResponse
- sling: Bound as is of type SlingScriptHelper
- resource: Bound as is of type Resource
- out: already bound by the JSP spec, nothing to be done
- flush: Bound as is of type boolean
- log: Bound as is of type org.slf4j.Logger
The variable names listed above (slingRequest, slingResponse, sling, resource, flush, log) may be overwritten by specifying another name in the defineObjects tag, such as <sling:defineObjects logName="logger" /> do use "logger" as the name of the "Logger".

(3) additional bindings only for JSP when using <sling:defineObjects>
Currently the sling:defineObjects tag provides further variables: the JCR Node to which the resource adapts, (optionally) the mapped object to which the resource adapts (if the respective class is declared), the resource resolver and the service locator. I suggest we just keep these variables, though they are most probably definitely overkill....

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (SLING-247) Provide Scripting variables as request attributes for JSP

Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/SLING-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595187#action_12595187 ] 

Carsten Ziegeler commented on SLING-247:
----------------------------------------

I think we should remove the resource resolver. To get the resource resolver, it's just "slingRequest.getResourceResolver()"

The service locator has already gone.

> Provide Scripting variables as request attributes for JSP
> ---------------------------------------------------------
>
>                 Key: SLING-247
>                 URL: https://issues.apache.org/jira/browse/SLING-247
>             Project: Sling
>          Issue Type: Improvement
>          Components: JSP
>            Reporter: Felix Meschberger
>            Assignee: Carsten Ziegeler
>             Fix For: 2.0.0
>
>
> The scripting variables defined in the SlingBIndings class are defined as global variables in script language bindings such as JavaScript and Velocity. In JSP this binding does not exist yet.
> The issue with JSP is, that JSPs are translated using a text-transformation to a Java class implementing the Servlet interface. As such there is no such thing as a global variable. A workaround to inject well known objects is implemented with <sling:defineObjects> tag. But this tag does not make the same defined variables available.
> I suggest to enhance JSP scripting as follows:
> (1) Bindings as Request Attributes
> All bindings defined in the SlingBindings object prepared for the script evaluation are stored as request attributes for use by the JSP.
> (2) Predefined bindings as variables through <sling:defineObjects>
> Some of the predefined bindings in the SlingBIndings object are mapped as variables in the JSP when using the <sling:defineObjects> tag. Some variable require special treatment:
> - request: The request variable already exists and is of type HttpServletRequest, the SlingHttpServletRequest object is bound as the slingRequest variable.
> - response: Same as for the request. The SlingHttpServletResponse object is bound as slingResponse
> - sling: Bound as is of type SlingScriptHelper
> - resource: Bound as is of type Resource
> - out: already bound by the JSP spec, nothing to be done
> - flush: Bound as is of type boolean
> - log: Bound as is of type org.slf4j.Logger
> The variable names listed above (slingRequest, slingResponse, sling, resource, flush, log) may be overwritten by specifying another name in the defineObjects tag, such as <sling:defineObjects logName="logger" /> do use "logger" as the name of the "Logger".
> (3) additional bindings only for JSP when using <sling:defineObjects>
> Currently the sling:defineObjects tag provides further variables: the JCR Node to which the resource adapts, (optionally) the mapped object to which the resource adapts (if the respective class is declared), the resource resolver and the service locator. I suggest we just keep these variables, though they are most probably definitely overkill....

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (SLING-247) Provide Scripting variables as request attributes for JSP

Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/SLING-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595223#action_12595223 ] 

Carsten Ziegeler commented on SLING-247:
----------------------------------------

As discussed on the mailing list: no need to support "flush"

Bindings won't be made available as request attributes, the SlingBindings will be available as a request attribute instead.

> Provide Scripting variables as request attributes for JSP
> ---------------------------------------------------------
>
>                 Key: SLING-247
>                 URL: https://issues.apache.org/jira/browse/SLING-247
>             Project: Sling
>          Issue Type: Improvement
>          Components: JSP
>            Reporter: Felix Meschberger
>            Assignee: Carsten Ziegeler
>             Fix For: 2.0.0
>
>
> The scripting variables defined in the SlingBIndings class are defined as global variables in script language bindings such as JavaScript and Velocity. In JSP this binding does not exist yet.
> The issue with JSP is, that JSPs are translated using a text-transformation to a Java class implementing the Servlet interface. As such there is no such thing as a global variable. A workaround to inject well known objects is implemented with <sling:defineObjects> tag. But this tag does not make the same defined variables available.
> I suggest to enhance JSP scripting as follows:
> (1) Bindings as Request Attributes
> All bindings defined in the SlingBindings object prepared for the script evaluation are stored as request attributes for use by the JSP.
> (2) Predefined bindings as variables through <sling:defineObjects>
> Some of the predefined bindings in the SlingBIndings object are mapped as variables in the JSP when using the <sling:defineObjects> tag. Some variable require special treatment:
> - request: The request variable already exists and is of type HttpServletRequest, the SlingHttpServletRequest object is bound as the slingRequest variable.
> - response: Same as for the request. The SlingHttpServletResponse object is bound as slingResponse
> - sling: Bound as is of type SlingScriptHelper
> - resource: Bound as is of type Resource
> - out: already bound by the JSP spec, nothing to be done
> - flush: Bound as is of type boolean
> - log: Bound as is of type org.slf4j.Logger
> The variable names listed above (slingRequest, slingResponse, sling, resource, flush, log) may be overwritten by specifying another name in the defineObjects tag, such as <sling:defineObjects logName="logger" /> do use "logger" as the name of the "Logger".
> (3) additional bindings only for JSP when using <sling:defineObjects>
> Currently the sling:defineObjects tag provides further variables: the JCR Node to which the resource adapts, (optionally) the mapped object to which the resource adapts (if the respective class is declared), the resource resolver and the service locator. I suggest we just keep these variables, though they are most probably definitely overkill....

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (SLING-247) Provide Scripting variables as request attributes for JSP

Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/SLING-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595225#action_12595225 ] 

Carsten Ziegeler commented on SLING-247:
----------------------------------------

As discussed on the mailing list, the support for object mapping will be removed as well.

> Provide Scripting variables as request attributes for JSP
> ---------------------------------------------------------
>
>                 Key: SLING-247
>                 URL: https://issues.apache.org/jira/browse/SLING-247
>             Project: Sling
>          Issue Type: Improvement
>          Components: JSP
>            Reporter: Felix Meschberger
>            Assignee: Carsten Ziegeler
>             Fix For: 2.0.0
>
>
> The scripting variables defined in the SlingBIndings class are defined as global variables in script language bindings such as JavaScript and Velocity. In JSP this binding does not exist yet.
> The issue with JSP is, that JSPs are translated using a text-transformation to a Java class implementing the Servlet interface. As such there is no such thing as a global variable. A workaround to inject well known objects is implemented with <sling:defineObjects> tag. But this tag does not make the same defined variables available.
> I suggest to enhance JSP scripting as follows:
> (1) Bindings as Request Attributes
> All bindings defined in the SlingBindings object prepared for the script evaluation are stored as request attributes for use by the JSP.
> (2) Predefined bindings as variables through <sling:defineObjects>
> Some of the predefined bindings in the SlingBIndings object are mapped as variables in the JSP when using the <sling:defineObjects> tag. Some variable require special treatment:
> - request: The request variable already exists and is of type HttpServletRequest, the SlingHttpServletRequest object is bound as the slingRequest variable.
> - response: Same as for the request. The SlingHttpServletResponse object is bound as slingResponse
> - sling: Bound as is of type SlingScriptHelper
> - resource: Bound as is of type Resource
> - out: already bound by the JSP spec, nothing to be done
> - flush: Bound as is of type boolean
> - log: Bound as is of type org.slf4j.Logger
> The variable names listed above (slingRequest, slingResponse, sling, resource, flush, log) may be overwritten by specifying another name in the defineObjects tag, such as <sling:defineObjects logName="logger" /> do use "logger" as the name of the "Logger".
> (3) additional bindings only for JSP when using <sling:defineObjects>
> Currently the sling:defineObjects tag provides further variables: the JCR Node to which the resource adapts, (optionally) the mapped object to which the resource adapts (if the respective class is declared), the resource resolver and the service locator. I suggest we just keep these variables, though they are most probably definitely overkill....

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (SLING-247) Provide Scripting variables as request attributes for JSP

Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/SLING-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595192#action_12595192 ] 

Carsten Ziegeler commented on SLING-247:
----------------------------------------

Rethinking again, I'll keep the resource resolver :)

> Provide Scripting variables as request attributes for JSP
> ---------------------------------------------------------
>
>                 Key: SLING-247
>                 URL: https://issues.apache.org/jira/browse/SLING-247
>             Project: Sling
>          Issue Type: Improvement
>          Components: JSP
>            Reporter: Felix Meschberger
>            Assignee: Carsten Ziegeler
>             Fix For: 2.0.0
>
>
> The scripting variables defined in the SlingBIndings class are defined as global variables in script language bindings such as JavaScript and Velocity. In JSP this binding does not exist yet.
> The issue with JSP is, that JSPs are translated using a text-transformation to a Java class implementing the Servlet interface. As such there is no such thing as a global variable. A workaround to inject well known objects is implemented with <sling:defineObjects> tag. But this tag does not make the same defined variables available.
> I suggest to enhance JSP scripting as follows:
> (1) Bindings as Request Attributes
> All bindings defined in the SlingBindings object prepared for the script evaluation are stored as request attributes for use by the JSP.
> (2) Predefined bindings as variables through <sling:defineObjects>
> Some of the predefined bindings in the SlingBIndings object are mapped as variables in the JSP when using the <sling:defineObjects> tag. Some variable require special treatment:
> - request: The request variable already exists and is of type HttpServletRequest, the SlingHttpServletRequest object is bound as the slingRequest variable.
> - response: Same as for the request. The SlingHttpServletResponse object is bound as slingResponse
> - sling: Bound as is of type SlingScriptHelper
> - resource: Bound as is of type Resource
> - out: already bound by the JSP spec, nothing to be done
> - flush: Bound as is of type boolean
> - log: Bound as is of type org.slf4j.Logger
> The variable names listed above (slingRequest, slingResponse, sling, resource, flush, log) may be overwritten by specifying another name in the defineObjects tag, such as <sling:defineObjects logName="logger" /> do use "logger" as the name of the "Logger".
> (3) additional bindings only for JSP when using <sling:defineObjects>
> Currently the sling:defineObjects tag provides further variables: the JCR Node to which the resource adapts, (optionally) the mapped object to which the resource adapts (if the respective class is declared), the resource resolver and the service locator. I suggest we just keep these variables, though they are most probably definitely overkill....

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Closed: (SLING-247) Provide Scripting variables as request attributes for JSP

Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SLING-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carsten Ziegeler closed SLING-247.
----------------------------------

    Resolution: Fixed

> Provide Scripting variables as request attributes for JSP
> ---------------------------------------------------------
>
>                 Key: SLING-247
>                 URL: https://issues.apache.org/jira/browse/SLING-247
>             Project: Sling
>          Issue Type: Improvement
>          Components: JSP
>            Reporter: Felix Meschberger
>            Assignee: Carsten Ziegeler
>             Fix For: 2.0.0
>
>
> The scripting variables defined in the SlingBIndings class are defined as global variables in script language bindings such as JavaScript and Velocity. In JSP this binding does not exist yet.
> The issue with JSP is, that JSPs are translated using a text-transformation to a Java class implementing the Servlet interface. As such there is no such thing as a global variable. A workaround to inject well known objects is implemented with <sling:defineObjects> tag. But this tag does not make the same defined variables available.
> I suggest to enhance JSP scripting as follows:
> (1) Bindings as Request Attributes
> All bindings defined in the SlingBindings object prepared for the script evaluation are stored as request attributes for use by the JSP.
> (2) Predefined bindings as variables through <sling:defineObjects>
> Some of the predefined bindings in the SlingBIndings object are mapped as variables in the JSP when using the <sling:defineObjects> tag. Some variable require special treatment:
> - request: The request variable already exists and is of type HttpServletRequest, the SlingHttpServletRequest object is bound as the slingRequest variable.
> - response: Same as for the request. The SlingHttpServletResponse object is bound as slingResponse
> - sling: Bound as is of type SlingScriptHelper
> - resource: Bound as is of type Resource
> - out: already bound by the JSP spec, nothing to be done
> - flush: Bound as is of type boolean
> - log: Bound as is of type org.slf4j.Logger
> The variable names listed above (slingRequest, slingResponse, sling, resource, flush, log) may be overwritten by specifying another name in the defineObjects tag, such as <sling:defineObjects logName="logger" /> do use "logger" as the name of the "Logger".
> (3) additional bindings only for JSP when using <sling:defineObjects>
> Currently the sling:defineObjects tag provides further variables: the JCR Node to which the resource adapts, (optionally) the mapped object to which the resource adapts (if the respective class is declared), the resource resolver and the service locator. I suggest we just keep these variables, though they are most probably definitely overkill....

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Assigned: (SLING-247) Provide Scripting variables as request attributes for JSP

Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SLING-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carsten Ziegeler reassigned SLING-247:
--------------------------------------

    Assignee: Carsten Ziegeler

> Provide Scripting variables as request attributes for JSP
> ---------------------------------------------------------
>
>                 Key: SLING-247
>                 URL: https://issues.apache.org/jira/browse/SLING-247
>             Project: Sling
>          Issue Type: Improvement
>          Components: JSP
>            Reporter: Felix Meschberger
>            Assignee: Carsten Ziegeler
>             Fix For: 2.0.0
>
>
> The scripting variables defined in the SlingBIndings class are defined as global variables in script language bindings such as JavaScript and Velocity. In JSP this binding does not exist yet.
> The issue with JSP is, that JSPs are translated using a text-transformation to a Java class implementing the Servlet interface. As such there is no such thing as a global variable. A workaround to inject well known objects is implemented with <sling:defineObjects> tag. But this tag does not make the same defined variables available.
> I suggest to enhance JSP scripting as follows:
> (1) Bindings as Request Attributes
> All bindings defined in the SlingBindings object prepared for the script evaluation are stored as request attributes for use by the JSP.
> (2) Predefined bindings as variables through <sling:defineObjects>
> Some of the predefined bindings in the SlingBIndings object are mapped as variables in the JSP when using the <sling:defineObjects> tag. Some variable require special treatment:
> - request: The request variable already exists and is of type HttpServletRequest, the SlingHttpServletRequest object is bound as the slingRequest variable.
> - response: Same as for the request. The SlingHttpServletResponse object is bound as slingResponse
> - sling: Bound as is of type SlingScriptHelper
> - resource: Bound as is of type Resource
> - out: already bound by the JSP spec, nothing to be done
> - flush: Bound as is of type boolean
> - log: Bound as is of type org.slf4j.Logger
> The variable names listed above (slingRequest, slingResponse, sling, resource, flush, log) may be overwritten by specifying another name in the defineObjects tag, such as <sling:defineObjects logName="logger" /> do use "logger" as the name of the "Logger".
> (3) additional bindings only for JSP when using <sling:defineObjects>
> Currently the sling:defineObjects tag provides further variables: the JCR Node to which the resource adapts, (optionally) the mapped object to which the resource adapts (if the respective class is declared), the resource resolver and the service locator. I suggest we just keep these variables, though they are most probably definitely overkill....

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.