[
https://issues.apache.org/jira/browse/SLING-3543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13990406#comment-13990406
]
Konrad Windszus commented on SLING-3543:
----------------------------------------
I see that this is more complicated than initially thought. I think that for
the beginning just exposing the bindings for the default context (request)
should be fine. But the problem really is, that we need to mock a lot of Sling
API objects (basically all the ones being defined by
DefaultSlingScript.verifySlingBindings which is SlingScriptHelper,
SlingHttpServletResponse, SlingHttpServletRequest, Resource, PrintWriter and
BufferedReader). That would be a lot of code.
Any other ideas, how to prevent to force all BindingsValuesProvider's to just
expose the bindings via Properties?
I thought about calling DefaultSlingScript.verifySlingBindings but that would
still require a real SlingHttpServletRequest.
> Provide a Felix Web Console Tab exposing the available Scripting Variables
> --------------------------------------------------------------------------
>
> Key: SLING-3543
> URL: https://issues.apache.org/jira/browse/SLING-3543
> Project: Sling
> Issue Type: Improvement
> Components: Scripting
> Affects Versions: Scripting Core 2.0.26
> Reporter: Konrad Windszus
>
> Currently you can very dynamically define the scripting variables
> (https://cwiki.apache.org/confluence/display/SLING/Adding+New+Scripting+Variables).
> Therefore it would be very good to expose which variables are exposed within
> each script provider in a dedicated web console tab.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
