On Fri, Sep 6, 2013 at 3:31 PM, Carsten Ziegeler cziege...@apache.org wrote:
...The constants should really be defined in the BVP class, this is the
service declaring them...
Good point, done in revision 1521017
... I don't understand what you mean by changes to existing code - this is
new,
On Fri, Sep 6, 2013 at 10:43 PM, Felix Meschberger fmesc...@adobe.com wrote:
Hmm, why not turning this around and ammed the BindingsValueProvider
interface ?
public interface BindingsValuesProvider2 extends BindingsValueProvider {
void addBindings(Bindings bindings, ScriptEngineFactory,
Hi
Am 09.09.2013 um 11:45 schrieb Bertrand Delacretaz:
On Fri, Sep 6, 2013 at 3:31 PM, Carsten Ziegeler cziege...@apache.org wrote:
...The constants should really be defined in the BVP class, this is the
service declaring them...
Good point, done in revision 1521017
Hmm. While this makes
Hi,
On Mon, Sep 9, 2013 at 3:26 PM, Felix Meschberger fmesc...@adobe.com wrote:
Am 09.09.2013 um 11:45 schrieb Bertrand Delacretaz:
...done in revision 1521017
...
You added a constant to the interface, so what will the export package
version be ? and the compatibility consequences ? Is this
Hi
What about Import-Package version ? Which is why I poke at the @ConsumerType
annotation.
@ConsumerType: We promise not to change the API unless we increase the major
version of the export
@ProviderType: We promise not to change the API unless we increase the minor
version of the export
On Thu, Sep 5, 2013 at 1:28 PM, Bertrand Delacretaz
bdelacre...@apache.org wrote:
...Maybe
addContextBindings(Bindings b, ScriptEngineFactory f, String context)
...
FYI I didn't do it like that in the end, as that would have caused
more changes than I like to existing code. The new service
The constants should really be defined in the BVP class, this is the
service declaring them
I don't understand what you mean by changes to existing code - this is
new, isn't it?
Carsten
2013/9/6 Bertrand Delacretaz bdelacre...@apache.org
On Thu, Sep 5, 2013 at 1:28 PM, Bertrand Delacretaz
Hmm, why not turning this around and ammed the BindingsValueProvider interface ?
public interface BindingsValuesProvider2 extends BindingsValueProvider {
void addBindings(Bindings bindings, ScriptEngineFactory, String context);
}
The BindingsValuesProvider2 is a marker interface to the
Hi Justin,
On Tuesday, August 6, 2013, Justin Edelson wrote:
...Whereas today you do:
ScriptEngineManager.getEngineByExtension(ecma)
You could do
ScriptEngineManager.getEngineByExtension(ecma, [healthcheck,
workflow]) ...
FYI, I'm getting back to this (SLING-3038) and the above won't work
What about defining a service (whatever name :) ) that has something like a:
applyBindings(Bindings b , String context)
method?
Internally this service can do whatever magic it has to do, like looking up
all BVPs with the specified context attribute set etc.
You prefill your bindings with the
On Thu, Sep 5, 2013 at 10:14 AM, Carsten Ziegeler cziege...@apache.org wrote:
What about defining a service (whatever name :) ) that has something like a:
applyBindings(Bindings b , String context)
method?...
Maybe
addContextBindings(Bindings b, ScriptEngineFactory f, String context)
As
If you need to know the language, can't we pass this as a string into the
service?
Other than that, add sounds good to me (don't know why I picked apply
anyway...)
Carsten
2013/9/5 Bertrand Delacretaz bdelacre...@apache.org
On Thu, Sep 5, 2013 at 10:14 AM, Carsten Ziegeler
On Thursday, September 5, 2013, Carsten Ziegeler wrote:
If you need to know the language, can't we pass this as a string into the
service?...
It's not only the language, some other ScriptEngineFactory metadata such as
compatible.javax.script.name is used.
Now, where should that new service
As our api is in the api bundle, well api it is :)
The package version will be 2.2.0 as this is adding new api
Carsten
2013/9/5 Bertrand Delacretaz bdelacre...@apache.org
On Thursday, September 5, 2013, Carsten Ziegeler wrote:
If you need to know the language, can't we pass this as a
Hi
Am 06.08.2013 um 20:26 schrieb Justin Edelson:
Hi Carsten,
I can't speak for exactly what Bertrand is thinking, but when I was
thinking about it, the scope/usage was an orthogonal concern to which
engine is selected.
Whereas today you do:
ScriptEngineManager.getEngineByExtension(ecma)
Hi
Am 07.08.2013 um 07:46 schrieb Carsten Ziegeler:
I'm not totally against this, but just adhoc adding this property without a
complete concept seems wrong to me. Defining the technical selection
process (e.g. as you describe it) is one part, but the other equally
important part, how to
On Wed, Aug 7, 2013 at 9:04 AM, Felix Meschberger fmesc...@adobe.com wrote:
...But there is not currently a way that a script could declare I am an HC
script or
I am a Request Processing script...
The missing piece here is that the HC scripts that I'm talking about
(and probably the workflow
Hi Bertrand
We don't really disagree at all ;-)
In fact having written my previous messages, I wonder, whether our default
values we provide to scripts (request, response, etc.) should not really be
provided by a BVP in the request (or such) scope/context/usage ;-)
Somehow I tend to get to
On Wed, Aug 7, 2013 at 9:43 AM, Felix Meschberger fmesc...@adobe.com wrote:
...In fact having written my previous messages, I wonder, whether our default
values we provide
to scripts (request, response, etc.) should not really be provided by a BVP
in the request (or such)
Here's my revised proposal based on this thread's discussions:
1. Add a context service property to our existing
BindingValuesProvider (BVP) implementations, value=request. The
context property can have multiple values.
2. Modify the scripting setup in DefaultSlingScript so that any BVP
which
Hi
Basically sounds good.
Am 07.08.2013 um 09:55 schrieb Bertrand Delacretaz:
Here's my revised proposal based on this thread's discussions:
1. Add a context service property to our existing
BindingValuesProvider (BVP) implementations, value=request. The
context property can have multiple
On Wed, Aug 7, 2013 at 10:09 AM, Felix Meschberger fmesc...@adobe.com wrote:
...In fact I would say, that BVPs without the property should just be used
anywhere
that might work - I was going to say that [1] for example makes no
sense in my health check context, but that provider is being
2013/8/7 Felix Meschberger fmesc...@adobe.com
A script, at the end of the day, executes some action and might or might
not expect some bindings (global variables in some languages). The script
would have to cope with them missing or of the wrong type or such... But
there is not currently a
Again, I'm still missing a suggestion on how to mark a script to run in a
given context.
Carsten
2013/8/7 Bertrand Delacretaz bdelacre...@apache.org
On Wed, Aug 7, 2013 at 10:09 AM, Felix Meschberger fmesc...@adobe.com
wrote:
...In fact I would say, that BVPs without the property should
On Wed, Aug 7, 2013 at 10:26 AM, Carsten Ziegeler cziege...@apache.org wrote:
Again, I'm still missing a suggestion on how to mark a script to run in a
given context...
You don't.
There are request processing scripts, the ones we have and always had
- there's no change for those, except that
Hmm, this doesn't really convince me. So this means there is no way to set
the context apart from creating/retrieving a script engine by hand (java
code)?
So scripts run with the usual Sling script resolution will always just use
BVPs not marked for any context and BVPs marked for the context
On Wed, Aug 7, 2013 at 11:47 AM, Carsten Ziegeler cziege...@apache.org wrote:
...scripts run with the usual Sling script resolution will always just use
BVPs not marked for any context and BVPs marked for the context request...
That's exactly the idea - no change for existing request processing
Hi,
I'd like to use BindingsValuesProvider services in my health check
module, to provide bindings like jmx for scripted health checks,
which should be ignored for general Sling scripting (or not - some
providers might apply to both general scripting and health checks).
I'm thinking of adding an
I'm not sure if I understand this 100% - from a scripting pov, how could I
set the usage value, let's say in a JSP (or any other script)?
Carsten
2013/8/6 Bertrand Delacretaz bdelacre...@apache.org
Hi,
I'd like to use BindingsValuesProvider services in my health check
module, to provide
On Tue, Aug 6, 2013 at 5:13 PM, Carsten Ziegeler cziege...@apache.org wrote:
I'm not sure if I understand this 100% - from a scripting pov, how could I
set the usage value, let's say in a JSP (or any other script)?
You set the usage property when you create a BindingsValuesProvider,
so for my
I guess this only works as you have a special script engine for health
check, right?
What if people want to use the same functionality if they write lets say
workflow scripts or wcm scripts etc?
As long as there is no way to make use of this in every script engine, I
don't see the point of adding
On Tue, Aug 6, 2013 at 5:39 PM, Carsten Ziegeler cziege...@apache.org wrote:
I guess this only works as you have a special script engine for health
check, right?
Not really a special script engine, but I'm using the
ScriptEngineManager directly instead of going through SlingScript.
See code at
I think if we would be in the jsp world, you would do a taglib for this -
of course taglibs are not usable within other scripting languages - so
depending on your script language you would have to come up with the
equivalent.
Taglibs in JSP allow exactly what you want - the BVP is more a way to
And forgot to mention :) I think your current approach is fine, as these
objects are special objects for health checks, you have special execution
code and can handle it there.
Carsten
2013/8/6 Carsten Ziegeler cziege...@apache.org
I think if we would be in the jsp world, you would do a
Hi Bertrand,
FWIW, I was thinking about something very similar (although I was thinking
of calling it 'scope', not 'usage'), but never got around to implementing
it.
+1 for me.
Justin
On Tue, Aug 6, 2013 at 10:58 AM, Bertrand Delacretaz bdelacre...@apache.org
wrote:
Hi,
I'd like to use
Ok, just to make it clear, as long as there is no support in all script
engines, I'm -1
Carsten
2013/8/6 Justin Edelson jus...@justinedelson.com
Hi Bertrand,
FWIW, I was thinking about something very similar (although I was thinking
of calling it 'scope', not 'usage'), but never got around
Hi Carsten,
I can't speak for exactly what Bertrand is thinking, but when I was
thinking about it, the scope/usage was an orthogonal concern to which
engine is selected.
Whereas today you do:
ScriptEngineManager.getEngineByExtension(ecma)
You could do
I'm not totally against this, but just adhoc adding this property without a
complete concept seems wrong to me. Defining the technical selection
process (e.g. as you describe it) is one part, but the other equally
important part, how to select from a script dev point of view. How can I
write a JSP
38 matches
Mail list logo
