Reduce dependencies of the scripting core

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

Reduce dependencies of the scripting core

Carsten Ziegeler
Hi,

currently our scripting core depends on the jcr api. This is an old
relict to support the optional binding for currentNode. If the current
resource is adaptable to a jcr node, then this binding is set to this node.
This binding is not officially supported :)

We should definitly either remove the dependency to jcr or make it
optional. This allows to use the scripting in a non jcr environment.

I think we should remove this support completly - afaik the only
scripting language that is affected by this change is the javascript
implementation. We could simply add the binding in this scripting
language. JSPs are not affected as we have a taglib there anyway.

So if noone objects, I'll remove the support from the scripting core and
add it to the javascript implementation.

As an alternative we could make the dependency optional and leave this
non official stuff in the core.

WDYT?

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

Re: Reduce dependencies of the scripting core

justinedelson
A few comments on this:
1) It seems like this would impact every scripting language *except* JSPs.
For example, I reference it on the page which describes the new
JSONGroovyBuilder (
http://cwiki.apache.org/confluence/display/SLING/Using+the+JSONGroovyBuilder
).

2) Removing without deprecation seems extreme, so at minimum,
http://cwiki.apache.org/SLING/scripting-variables.html (amongst others)
should be updated ASAP to explain that currentNode shouldn't be used.

3) I've been kicking around the idea that it would be nice for the scripting
binding to be expandable. Given a service interface like this:

public interface SlingScriptBindingValuesProvider {
 void addBindings(Bindings bindings);
}

DefaultSlingScript could then find all services and invoke them. A service
property could be used to limit the scope of a provider to one or more
scripting languages (for example, the JSONGroovyBuilder should only go into
the binding for Groovy scripts).

If this was done, then currentNode could be kept in the binding by creating
a SlingScriptBindingValuesProvider in one of the jcr bundles and the jcr
dependency could be removed from scripting core. Of course now there's a
dependency between a jcr bundle and scripting API, but perhaps that could be
optional (or, at least, acceptable).

This is somewhat half-baked and I haven't had enough time to figure out if
this is practical, but this did seem like a reasonable time to mention it.

Justin

On Wed, Jan 6, 2010 at 3:14 PM, Carsten Ziegeler <[hidden email]>wrote:

> Hi,
>
> currently our scripting core depends on the jcr api. This is an old
> relict to support the optional binding for currentNode. If the current
> resource is adaptable to a jcr node, then this binding is set to this node.
> This binding is not officially supported :)
>
> We should definitly either remove the dependency to jcr or make it
> optional. This allows to use the scripting in a non jcr environment.
>
> I think we should remove this support completly - afaik the only
> scripting language that is affected by this change is the javascript
> implementation. We could simply add the binding in this scripting
> language. JSPs are not affected as we have a taglib there anyway.
>
> So if noone objects, I'll remove the support from the scripting core and
> add it to the javascript implementation.
>
> As an alternative we could make the dependency optional and leave this
> non official stuff in the core.
>
> WDYT?
>
> Carsten
> --
> Carsten Ziegeler
> [hidden email]
>
Reply | Threaded
Open this post in threaded view
|

Re: Reduce dependencies of the scripting core

Felix Meschberger-2
In reply to this post by Carsten Ziegeler
Hi,

On 06.01.2010 21:14, Carsten Ziegeler wrote:
> Hi,
>
> currently our scripting core depends on the jcr api. This is an old
> relict to support the optional binding for currentNode. If the current
> resource is adaptable to a jcr node, then this binding is set to this node.
> This binding is not officially supported :)

Well, actually this variable is documented in the Sling Wiki Scripting
Variables page [1]. And thus it looks like it is kind of officially
supported.

>
> We should definitly either remove the dependency to jcr or make it
> optional. This allows to use the scripting in a non jcr environment.
>
> I think we should remove this support completly - afaik the only
> scripting language that is affected by this change is the javascript
> implementation. We could simply add the binding in this scripting
> language. JSPs are not affected as we have a taglib there anyway.

Yes, for JSPs the currentNode variable is set by the
<sling:defineObjects> tag.

> So if noone objects, I'll remove the support from the scripting core and
> add it to the javascript implementation.
>
> As an alternative we could make the dependency optional and leave this
> non official stuff in the core.
>
> WDYT?

Upfront I would be for removing. But since the variable is documented
and therefore de-facto API, I think we should implement the workaround
with the optional dependency.

Regards
Felix

>
> Carsten

[1] http://cwiki.apache.org/SLING/scripting-variables.html
Reply | Threaded
Open this post in threaded view
|

Re: Reduce dependencies of the scripting core

Felix Meschberger-2
In reply to this post by justinedelson
Hi,

On 06.01.2010 22:16, Justin Edelson wrote:

> A few comments on this:
> 1) It seems like this would impact every scripting language *except* JSPs.
> For example, I reference it on the page which describes the new
> JSONGroovyBuilder (
> http://cwiki.apache.org/confluence/display/SLING/Using+the+JSONGroovyBuilder
> ).
>
> 2) Removing without deprecation seems extreme, so at minimum,
> http://cwiki.apache.org/SLING/scripting-variables.html (amongst others)
> should be updated ASAP to explain that currentNode shouldn't be used.
>
> 3) I've been kicking around the idea that it would be nice for the scripting
> binding to be expandable. Given a service interface like this:
>
> public interface SlingScriptBindingValuesProvider {
>  void addBindings(Bindings bindings);
> }
>
> DefaultSlingScript could then find all services and invoke them. A service
> property could be used to limit the scope of a provider to one or more
> scripting languages (for example, the JSONGroovyBuilder should only go into
> the binding for Groovy scripts).
>
> If this was done, then currentNode could be kept in the binding by creating
> a SlingScriptBindingValuesProvider in one of the jcr bundles and the jcr
> dependency could be removed from scripting core. Of course now there's a
> dependency between a jcr bundle and scripting API, but perhaps that could be
> optional (or, at least, acceptable).

This sounds like an interesting approach, indeed !

Regards
Felix

>
> This is somewhat half-baked and I haven't had enough time to figure out if
> this is practical, but this did seem like a reasonable time to mention it.
>
> Justin
>
> On Wed, Jan 6, 2010 at 3:14 PM, Carsten Ziegeler <[hidden email]>wrote:
>
>> Hi,
>>
>> currently our scripting core depends on the jcr api. This is an old
>> relict to support the optional binding for currentNode. If the current
>> resource is adaptable to a jcr node, then this binding is set to this node.
>> This binding is not officially supported :)
>>
>> We should definitly either remove the dependency to jcr or make it
>> optional. This allows to use the scripting in a non jcr environment.
>>
>> I think we should remove this support completly - afaik the only
>> scripting language that is affected by this change is the javascript
>> implementation. We could simply add the binding in this scripting
>> language. JSPs are not affected as we have a taglib there anyway.
>>
>> So if noone objects, I'll remove the support from the scripting core and
>> add it to the javascript implementation.
>>
>> As an alternative we could make the dependency optional and leave this
>> non official stuff in the core.
>>
>> WDYT?
>>
>> Carsten
>> --
>> Carsten Ziegeler
>> [hidden email]
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Reduce dependencies of the scripting core

justinedelson
On 1/6/10 4:33 PM, Felix Meschberger wrote:

> Hi,
>
> On 06.01.2010 22:16, Justin Edelson wrote:
>    
>> 3) I've been kicking around the idea that it would be nice for the scripting
>> binding to be expandable. Given a service interface like this:
>>
>> public interface SlingScriptBindingValuesProvider {
>>   void addBindings(Bindings bindings);
>> }
>>
>> DefaultSlingScript could then find all services and invoke them. A service
>> property could be used to limit the scope of a provider to one or more
>> scripting languages (for example, the JSONGroovyBuilder should only go into
>> the binding for Groovy scripts).
>>
>> If this was done, then currentNode could be kept in the binding by creating
>> a SlingScriptBindingValuesProvider in one of the jcr bundles and the jcr
>> dependency could be removed from scripting core. Of course now there's a
>> dependency between a jcr bundle and scripting API, but perhaps that could be
>> optional (or, at least, acceptable).
>>      
> This sounds like an interesting approach, indeed !
>
> Regards
> Felix
>
>    
interesting == good or interesting == bad?

Reply | Threaded
Open this post in threaded view
|

Re: Reduce dependencies of the scripting core

Felix Meschberger-2
Hi,

On 07.01.2010 03:59, Justin Edelson wrote:

> On 1/6/10 4:33 PM, Felix Meschberger wrote:
>> Hi,
>>
>> On 06.01.2010 22:16, Justin Edelson wrote:
>>  
>>> 3) I've been kicking around the idea that it would be nice for the
>>> scripting
>>> binding to be expandable. Given a service interface like this:
>>>
>>> public interface SlingScriptBindingValuesProvider {
>>>   void addBindings(Bindings bindings);
>>> }
>>>
>>> DefaultSlingScript could then find all services and invoke them. A
>>> service
>>> property could be used to limit the scope of a provider to one or more
>>> scripting languages (for example, the JSONGroovyBuilder should only
>>> go into
>>> the binding for Groovy scripts).
>>>
>>> If this was done, then currentNode could be kept in the binding by
>>> creating
>>> a SlingScriptBindingValuesProvider in one of the jcr bundles and the jcr
>>> dependency could be removed from scripting core. Of course now there's a
>>> dependency between a jcr bundle and scripting API, but perhaps that
>>> could be
>>> optional (or, at least, acceptable).
>>>      
>> This sounds like an interesting approach, indeed !
>>
>> Regards
>> Felix
>>
>>    
> interesting == good or interesting == bad?
>
>

interesting == good == definitely worth following up on

Regards
Felix
Reply | Threaded
Open this post in threaded view
|

Re: Reduce dependencies of the scripting core

Bertrand Delacretaz
In reply to this post by Carsten Ziegeler
Hi,

On Wed, Jan 6, 2010 at 9:14 PM, Carsten Ziegeler <[hidden email]> wrote:
> ...currently our scripting core depends on the jcr api. This is an old
> relict to support the optional binding for currentNode. If the current
> resource is adaptable to a jcr node, then this binding is set to this node.
> This binding is not officially supported :)...

As Google search for "sling currentnode" shows, there are quite a
number of examples (in addition to our own docs) which refer to this
currentNode binding.

So I agree we others that we should keep it, Justin's proposed
SlingScriptBindingValuesProvider looks like a good idea.

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

Re: Reduce dependencies of the scripting core

Carsten Ziegeler
In reply to this post by justinedelson
Justin Edelson wrote:
> A few comments on this:
> 1) It seems like this would impact every scripting language *except* JSPs.
> For example, I reference it on the page which describes the new
> JSONGroovyBuilder (
> http://cwiki.apache.org/confluence/display/SLING/Using+the+JSONGroovyBuilder
> ).
Yes, in fact you're right - unfortunately :) We should really avoid
using this as usually the resource interfacee in combination with a
value map (which you can get using the ResourceUtil) is sufficient and
much more portable and readable.

>
> 2) Removing without deprecation seems extreme, so at minimum,
> http://cwiki.apache.org/SLING/scripting-variables.html (amongst others)
> should be updated ASAP to explain that currentNode shouldn't be used.
Yes, I'll update the docs.

>
> 3) I've been kicking around the idea that it would be nice for the scripting
> binding to be expandable. Given a service interface like this:
>
> public interface SlingScriptBindingValuesProvider {
>  void addBindings(Bindings bindings);
> }
>
Yes, I thought about this, too. The question is how to define the
interface. I don't want to give providers the possibility th
change/replace already set bindings. So they should just be able to add
stuff.

> DefaultSlingScript could then find all services and invoke them. A service
> property could be used to limit the scope of a provider to one or more
> scripting languages (for example, the JSONGroovyBuilder should only go into
> the binding for Groovy scripts).
>
> If this was done, then currentNode could be kept in the binding by creating
> a SlingScriptBindingValuesProvider in one of the jcr bundles and the jcr
> dependency could be removed from scripting core. Of course now there's a
> dependency between a jcr bundle and scripting API, but perhaps that could be
> optional (or, at least, acceptable).
I think, that would be fine.

>
> This is somewhat half-baked and I haven't had enough time to figure out if
> this is practical, but this did seem like a reasonable time to mention it.
Yes, definitly. I'll start with making the dependency optional. And we
can continue this discussion in the meantime.

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

Re: Reduce dependencies of the scripting core

Carsten Ziegeler
In reply to this post by Felix Meschberger-2
Felix Meschberger wrote:
> Well, actually this variable is documented in the Sling Wiki Scripting
> Variables page [1]. And thus it looks like it is kind of officially
> supported.
Yepp, unfortunately.

>
> Upfront I would be for removing. But since the variable is documented
> and therefore de-facto API, I think we should implement the workaround
> with the optional dependency.
>
Agreed.

Carsten

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

Re: Reduce dependencies of the scripting core

justinedelson
In reply to this post by Carsten Ziegeler
On 1/7/10 3:06 AM, Carsten Ziegeler wrote:

> Justin Edelson wrote:
>    
>> 3) I've been kicking around the idea that it would be nice for the scripting
>> binding to be expandable. Given a service interface like this:
>>
>> public interface SlingScriptBindingValuesProvider {
>>   void addBindings(Bindings bindings);
>> }
>>
>>      
> Yes, I thought about this, too. The question is how to define the
> interface. I don't want to give providers the possibility th
> change/replace already set bindings. So they should just be able to add
> stuff.
>
>    
Indeed. What I was thinking is to make the Bindings pass to the provider
service methods be a proxy to the actual Bindings object. This proxy
would throw UnsupportedOperationException on remove(),
IllegalArgumentException on a put() with a pre-existing name, and add
only new keys on a putAll().

That said, I haven't looked at the JSP Taglib bundle to see how these
providers might be integrated. Ideally, you'd be able to write a single
provider and get support for adding values for both JSPs and Scripting.

Justin