On Feb 17, 2008 10:51 PM, Lars Trieloff [EMAIL PROTECTED] wrote:
...I think this would be the easiest way of accessing the
node variable in scripts, it would work across all scripting languages
and if we call the variable currentNode we would benefit from
1) being drop-in compatible with JST
Hi,
Am Montag, den 18.02.2008, 09:50 +0100 schrieb Bertrand Delacretaz:
On Feb 17, 2008 10:51 PM, Lars Trieloff [EMAIL PROTECTED] wrote:
...I think this would be the easiest way of accessing the
node variable in scripts, it would work across all scripting languages
and if we call the
David Nuescheler wrote:
Hi guys,
I agree with Lars.
on top of that I would like to mention the following things:
(1) I feel like with a getChildren() method we slowly see
parts of the Node interface sneak in through the back door.
I think it is fairly public that I am not a big fan of the
Hi Carsten,
I have to disagree. Treating all languages the same will result in an
API that does not match the concepts of most languages supported.
Different programming languages have different concepts and if possible,
we should support these concepts.
This does not interfere with implementing
Hi guys,
I agree with Lars.
on top of that I would like to mention the following things:
(1) I feel like with a getChildren() method we slowly see
parts of the Node interface sneak in through the back door.
I think it is fairly public that I am not a big fan of the abstraction
from Node but now
Am 15.02.2008 um 16:27 schrieb David Nuescheler:
I think we should
even think of Resources that do not even have the concept of a
hierarchy
No, the hierarchy of resources drives the mapping of URLs to
resources. Therefore sling depends on that, and IMHO it should be part
of the
Hi all,
I have been rethinking all these and also Carsten's input on our past
discussion regarding intelligence of a Resource. I also looked at the
API and the intentions of it again, which I summarize as follows:
Resource - The object representating some datum in Sling. This may be
a JCR
Argh, I must have hit a secret key that sends the mail before it was
finished, here's the full story:
Now, rethinking as well :) I would also go one step further
All languages should be treated the same. It's too confusing that one
script language provides additional behaviour/methods on
Personally, I don't care if I write 10, 30 or 60 characters to get a handle
to an object which lets me access all available methods for the resource
node, or the system as such.
Either way you choose, just make sure to add the list of availabel methods
to some page in the wiki, so that all script
A resource should not provide a way to get the resource resolver. I
think this is the root cause of the problem (ok, so far it is actually
the resource provider). We already have a way to get the resource
resolver and that's the request object, so instead of using:
hi,
I don't like this, and here is why: By adding this method, you add
functionality to a single location creating the impression, that this is
core functionality. That is you create a JavaScript-only
Resource.listChildren() method. The problem with this is, that migrating
such code to
Felix Meschberger wrote:
Hi,
I don't like this, and here is why: By adding this method, you add
functionality to a single location creating the impression, that this is
core functionality. That is you create a JavaScript-only
Resource.listChildren() method. The problem with this is, that
On Feb 11, 2008 8:26 AM, Felix Meschberger [EMAIL PROTECTED] wrote:
...That is you create a JavaScript-only
Resource.listChildren() method. The problem with this is, that migrating
such code to e.g. Java or trying to create similar code in other
languages will create tons of issues
Hi,
I don't like this, and here is why: By adding this method, you add
functionality to a single location creating the impression, that this is
core functionality. That is you create a JavaScript-only
Resource.listChildren() method. The problem with this is, that migrating
such code to e.g. Java
14 matches
Mail list logo
