SLING_ prefix for selectors that we use "internally" ?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

SLING_ prefix for selectors that we use "internally" ?

Bertrand Delacretaz
Hi,

The webconsole plugin that was just contributed for In
https://issues.apache.org/jira/browse/SLING-3543 needs a specific
selector to retrieve scripting variables from the HTTP client.

Currently it's using "SLING_availablebindings" as its selector, with a
SLING_ prefix to make collisions with user-defined selectors less
likely.

Shall we use this prefix from now on in similar cases?

Do we already have such cases where "our" selectors might get in the
way of Sling users?

-Bertrand
Reply | Threaded
Open this post in threaded view
|

Re: SLING_ prefix for selectors that we use "internally" ?

Carsten Ziegeler
Bertrand Delacretaz wrote

> Hi,
>
> The webconsole plugin that was just contributed for In
> https://issues.apache.org/jira/browse/SLING-3543 needs a specific
> selector to retrieve scripting variables from the HTTP client.
>
> Currently it's using "SLING_availablebindings" as its selector, with a
> SLING_ prefix to make collisions with user-defined selectors less
> likely.
>
> Shall we use this prefix from now on in similar cases?
>
> Do we already have such cases where "our" selectors might get in the
> way of Sling users?
>
We already have selectors in some modules and never used a "SLING_" prefix.
And I don't think this is necessary here either. The script is usually
selected by the combination of resource type, selector and extension.
So even if someone is using the rather rare availablebindings selector
we only get into a collision if resource type and extension are the same.

Regards
Carsten

 

--
Carsten Ziegeler
Adobe Research Switzerland
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SLING_ prefix for selectors that we use "internally" ?

Bertrand Delacretaz
On Tue, Feb 28, 2017 at 11:44 AM, Carsten Ziegeler <[hidden email]> wrote:
> ...The script is usually selected by the combination of resource type, selector and extension...

The SlingBindingsVariablesListJsonServlet [1] has to use the
sling/servlet/default resource type, by design, so I think the prefix
is useful here.

-Bertrand

[1] https://svn.apache.org/repos/asf/sling/trunk/bundles/scripting/core/src/main/java/org/apache/sling/scripting/core/impl/SlingBindingsVariablesListJsonServlet.java
Reply | Threaded
Open this post in threaded view
|

Re: SLING_ prefix for selectors that we use "internally" ?

Felix Meschberger-3
Hi

But if you insiste on a prefix, I suggest to use something nicer looking than SLING_.

How about sling. ? Hence sling.bla such as /path/to/resource.sling.bla.html ?

Yet, I agree with Carsten that I am not sure, whether this really is required. On the other hand, using a specific selector would make it easier to filter selectors through a proxy...

Regards
Felix

> Am 28.02.2017 um 14:24 schrieb Bertrand Delacretaz <[hidden email]>:
>
> On Tue, Feb 28, 2017 at 11:44 AM, Carsten Ziegeler <[hidden email]> wrote:
>> ...The script is usually selected by the combination of resource type, selector and extension...
>
> The SlingBindingsVariablesListJsonServlet [1] has to use the
> sling/servlet/default resource type, by design, so I think the prefix
> is useful here.
>
> -Bertrand
>
> [1] https://svn.apache.org/repos/asf/sling/trunk/bundles/scripting/core/src/main/java/org/apache/sling/scripting/core/impl/SlingBindingsVariablesListJsonServlet.java

Reply | Threaded
Open this post in threaded view
|

Re: SLING_ prefix for selectors that we use "internally" ?

Carsten Ziegeler
In reply to this post by Bertrand Delacretaz
Bertrand Delacretaz wrote
> On Tue, Feb 28, 2017 at 11:44 AM, Carsten Ziegeler <[hidden email]> wrote:
>> ...The script is usually selected by the combination of resource type, selector and extension...
>
> The SlingBindingsVariablesListJsonServlet [1] has to use the
> sling/servlet/default resource type, by design, so I think the prefix
> is useful here.
>

How is that resource type different from others?

Carsten

--
Carsten Ziegeler
Adobe Research Switzerland
[hidden email]