You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2008/02/11 09:11:18 UTC
Re: [PROPOSAL]: Add Resource.listChildren() method
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 migrating
> such code to e.g. Java or trying to create similar code in other
> languages will create tons of issues.
>
> In addition, this implementation does not actually work, because it only
> considers children of the current resource's ResourceProvider neglecting
> any other ResourceProviders which might have "children" to the resource.
>
> I understand, that it is cumbersome to revert to the ResourceResolver to
> list the children of a resource - not just in JavaScript. So I would
> like to propose these changes to the Resource interface:
>
>
> Add Methods:
> Iterator<Resource> listChildren(); // equivalent to
> getResourceResolver().listChildren()
> ResourceResolver getResourceResolver();
>
> Remove Method:
> ResourceProvider getResourceProvider(); // replaced by
> getResourceResolver()
>
I'm not against these changes, but I think we discussed this some months
ago when we
discussed the Resource interface. And there were some arguments against
doing this (which I can't remember and haven't looked up).
I just hope that we are not going back and force with adding and
removing method just because someone needs them somewhere.
For now, I think adding the getResourceResolver and removing
getResourceProvider should be sufficient. I see no real value in adding
the listChildren method which is just a shortcut.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [PROPOSAL]: Add Resource.listChildren() method
Posted by Tobias Bocanegra <to...@day.com>.
> 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:
> resource.getResourceResolver().listChildren(resource)
> you use
> request.getResourceResolver().listChildren(resource)
> which frees us from passing the resource resolver to the providers.
> And it's even much cleaner as a resource does not need to know anything
> about the resource resolver.
i disagree. decoupling the resource from the resolver (or any other
'session object') was IMO the biggest flaw in the initial OCM based
sling. it might be sufficient in a scripting env. where the 'request'
is always available - but in all other cases it's very tiresome to
pass the request/resolver everywhere. furthermore, that the 'Node'
already has the session - removing it on the resource
level is weird.
> I don't think that going this clean api way :) is too much to type for
> all our script fans here. Assuming that you iterate over children once
> in a script, you have to type approx. 30 more characters - compared to
> the overall size of a script its negletable :)
> Ok, more seriously, this gives us well defined
regards, toby
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: [PROPOSAL]: Add Resource.listChildren() method
Posted by Peter Svensson <ps...@gmail.com>.
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 authors know what the 'magic
words' are when accessing resources.
Cheers,
PS
On Feb 13, 2008 9:42 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> 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 objects that
> other language do not provide. This will cause problems over time.
>
> 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:
> resource.getResourceResolver().listChildren(resource)
> you use
> request.getResourceResolver().listChildren(resource)
> which frees us from passing the resource resolver to the providers.
> And it's even much cleaner as a resource does not need to know anything
> about the resource resolver.
>
> I don't think that going this clean api way :) is too much to type for
> all our script fans here. Assuming that you iterate over children once
> in a script, you have to type approx. 30 more characters - compared to
> the overall size of a script its negletable :)
> Ok, more seriously, this gives us well defined
>
> Felix Meschberger wrote:
> > 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 Node or
> > Property or an OSGi Bundle resource or an OS filesystem file.
> > ResourceResolver - The object providing access to Resource instances
> > from the
> > application context. The ResourceResolver represents the
> > external view of
> > the Resource tree.
> > ResourceProvider - The object capable of representing certain data as
> > Resource
> > objects.
> >
> > The ResourceResolver interface is typically implemented once. It
> > incorporates the logic of dealing with multiple ResourceProvider
> > services. ResourceProvider instances may be provided by multiple parties
> > outside of the scope of the ResourceResolver. The ResourceProvider
> > instances are the factories of Resource objects: The ResourceResolver
> > asks the ResourceProvider for the creation of Resource objects. That is,
> > Resource objects are created under the auspices of the ResourceProvider
> > and not of the ResourceResolver.
> >
> > What this means is, that Resource objects have absolutely no means of
> > accessing the mechanism of how a ResourceResolver uses ResourceProvider
> > services to find and create Resource objects. Consequently, the Resource
> > cannot list children and cannot access relative resources.
> >
> > Therefore I have to revert and agree with Carsten, that any such child
> > and relative resource accessor methods must be provided by the
> > ResourceResolver. Any such API on the Resource interface may always only
> > be defined in terms of "implemented by calling the respective methods on
> > the ResourceResolver object". Thus defining such an API prescribes an
> > actual implementation, which is not the best of all things to be done by
> > an API ;-) Unless we define Resource as an abstract class with child and
> > relative resource accessor methods already implemented.
> >
> > Undisputed is the fact, that the Resource should have a link to the
> > ResourceResolver and not to the ResourceProvider. In this respect, the
> > ResourceProvider interface will have to be enhanced to take the
> > ResourceResolver asking for a Resource from the ResourceProvider.
> >
> > Remains the question of whether we actually should provide additional
> > public methods and properties on an interface in a single scripting
> > language which is not available in any other context. In other words: Is
> > it ok to have a JavaScript "Resource" host object with a "children"
> > property not matched by a respective Resource.getChildren() method ?
> > Wouldn't this be too confusing ?
> >
> > Regards
> > Felix
> >
> > Am Montag, den 11.02.2008, 09:11 +0100 schrieb Carsten Ziegeler:
> >> 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
> migrating
> >>> such code to e.g. Java or trying to create similar code in other
> >>> languages will create tons of issues.
> >>>
> >>> In addition, this implementation does not actually work, because it
> only
> >>> considers children of the current resource's ResourceProvider
> neglecting
> >>> any other ResourceProviders which might have "children" to the
> resource.
> >>>
> >>> I understand, that it is cumbersome to revert to the ResourceResolver
> to
> >>> list the children of a resource - not just in JavaScript. So I would
> >>> like to propose these changes to the Resource interface:
> >>>
> >>>
> >>> Add Methods:
> >>> Iterator<Resource> listChildren(); // equivalent to
> >>> getResourceResolver().listChildren()
> >>> ResourceResolver getResourceResolver();
> >>>
> >>> Remove Method:
> >>> ResourceProvider getResourceProvider(); // replaced by
> >>> getResourceResolver()
> >>>
> >> I'm not against these changes, but I think we discussed this some
> months
> >> ago when we
> >> discussed the Resource interface. And there were some arguments against
> >> doing this (which I can't remember and haven't looked up).
> >> I just hope that we are not going back and force with adding and
> >> removing method just because someone needs them somewhere.
> >> For now, I think adding the getResourceResolver and removing
> >> getResourceProvider should be sufficient. I see no real value in adding
> >> the listChildren method which is just a shortcut.
> >>
> >> Carsten
> >>
> >
> >
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
Re: [PROPOSAL]: Add Resource.listChildren() method
Posted by Alexander Klimetschek <ak...@day.com>.
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 resource's implementation to map its internals to a tree
structure. If not, an important part of the definition of a resource
is lost and sling's resource tree abstraction would get mixed up.
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: [PROPOSAL]: Add Resource.listChildren() method
Posted by Philipp Koch <ph...@day.com>.
> (2) I would really like to table the sling API discussions for a while
> and let us all gather some experience with what we have before we
> we start modifying the API. From my personal perspective the
> constant change in the sling API is the biggest problem for the
> few early adopters we have.
i very much agree since i have been using sling since the very
beginning. it was always a pain and sometimes very frustrating to
adapt the sling app to the latest sling changes (which happend to
happen very often). i think that the sling api evolved very well
looking at the api at the very beginning and now.
regrads,
philipp
On 2/15/08, David Nuescheler <da...@day.com> 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 abstraction
> from Node but now that we have the abstraction I think we should
> even think of Resources that do not even the concept of a hierarchy.
>
> (2) I would really like to table the sling API discussions for a while
> and let us all gather some experience with what we have before we
> we start modifying the API. From my personal perspective the
> constant change in the sling API is the biggest problem for the
> few early adopters we have.
>
> just my two cents...
>
> regards,
>
> david
>
>
> On 2/15/08, Lars Trieloff <la...@trieloff.net> wrote:
> > 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 the listChildren() method in a
> > clean way, but we should also keep in mind that some languages we
> > support do not have a concept of methods alltogether (Javascript,
> > Velocity, Freemarker), some are dynamically typed and some are untyped.
> >
> > By disregarding this fact we create a cumbersome API that feels like the
> > DOM API (that was designed to be language-independent and lead to
> > implementations like DOM4j or JDOM that fit better to the concepts of
> > the programming language environment)
> >
> > To sum it up: When implementing scripting support, we should allow the
> > scriptingengine to add additional convenience accessors and type
> > conversions, but we should not implement some concepts (like
> > listChildren()) exclusively for one language.
> >
> > regards,
> >
> >
> > Lars
> >
> >
> > On Wed, 2008-02-13 at 09:42 +0100, Carsten Ziegeler wrote:
> > > 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 objects that
> > > other language do not provide. This will cause problems over time.
> > >
> > > 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:
> > > resource.getResourceResolver().listChildren(resource)
> > > you use
> > > request.getResourceResolver().listChildren(resource)
> > > which frees us from passing the resource resolver to the providers.
> > > And it's even much cleaner as a resource does not need to know anything
> > > about the resource resolver.
> > >
> > > I don't think that going this clean api way :) is too much to type for
> > > all our script fans here. Assuming that you iterate over children once
> > > in a script, you have to type approx. 30 more characters - compared to
> > > the overall size of a script its negletable :)
> > > Ok, more seriously, this gives us well defined
> > >
> > > Felix Meschberger wrote:
> > > > 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 Node or
> > > > Property or an OSGi Bundle resource or an OS filesystem file.
> > > > ResourceResolver - The object providing access to Resource instances
> > > > from the
> > > > application context. The ResourceResolver represents the
> > > > external view of
> > > > the Resource tree.
> > > > ResourceProvider - The object capable of representing certain data as
> > > > Resource
> > > > objects.
> > > >
> > > > The ResourceResolver interface is typically implemented once. It
> > > > incorporates the logic of dealing with multiple ResourceProvider
> > > > services. ResourceProvider instances may be provided by multiple parties
> > > > outside of the scope of the ResourceResolver. The ResourceProvider
> > > > instances are the factories of Resource objects: The ResourceResolver
> > > > asks the ResourceProvider for the creation of Resource objects. That is,
> > > > Resource objects are created under the auspices of the ResourceProvider
> > > > and not of the ResourceResolver.
> > > >
> > > > What this means is, that Resource objects have absolutely no means of
> > > > accessing the mechanism of how a ResourceResolver uses ResourceProvider
> > > > services to find and create Resource objects. Consequently, the Resource
> > > > cannot list children and cannot access relative resources.
> > > >
> > > > Therefore I have to revert and agree with Carsten, that any such child
> > > > and relative resource accessor methods must be provided by the
> > > > ResourceResolver. Any such API on the Resource interface may always only
> > > > be defined in terms of "implemented by calling the respective methods on
> > > > the ResourceResolver object". Thus defining such an API prescribes an
> > > > actual implementation, which is not the best of all things to be done by
> > > > an API ;-) Unless we define Resource as an abstract class with child and
> > > > relative resource accessor methods already implemented.
> > > >
> > > > Undisputed is the fact, that the Resource should have a link to the
> > > > ResourceResolver and not to the ResourceProvider. In this respect, the
> > > > ResourceProvider interface will have to be enhanced to take the
> > > > ResourceResolver asking for a Resource from the ResourceProvider.
> > > >
> > > > Remains the question of whether we actually should provide additional
> > > > public methods and properties on an interface in a single scripting
> > > > language which is not available in any other context. In other words: Is
> > > > it ok to have a JavaScript "Resource" host object with a "children"
> > > > property not matched by a respective Resource.getChildren() method ?
> > > > Wouldn't this be too confusing ?
> > > >
> > > > Regards
> > > > Felix
> > > >
> > > > Am Montag, den 11.02.2008, 09:11 +0100 schrieb Carsten Ziegeler:
> > > >> 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 migrating
> > > >>> such code to e.g. Java or trying to create similar code in other
> > > >>> languages will create tons of issues.
> > > >>>
> > > >>> In addition, this implementation does not actually work, because it only
> > > >>> considers children of the current resource's ResourceProvider neglecting
> > > >>> any other ResourceProviders which might have "children" to the resource.
> > > >>>
> > > >>> I understand, that it is cumbersome to revert to the ResourceResolver to
> > > >>> list the children of a resource - not just in JavaScript. So I would
> > > >>> like to propose these changes to the Resource interface:
> > > >>>
> > > >>>
> > > >>> Add Methods:
> > > >>> Iterator<Resource> listChildren(); // equivalent to
> > > >>> getResourceResolver().listChildren()
> > > >>> ResourceResolver getResourceResolver();
> > > >>>
> > > >>> Remove Method:
> > > >>> ResourceProvider getResourceProvider(); // replaced by
> > > >>> getResourceResolver()
> > > >>>
> > > >> I'm not against these changes, but I think we discussed this some months
> > > >> ago when we
> > > >> discussed the Resource interface. And there were some arguments against
> > > >> doing this (which I can't remember and haven't looked up).
> > > >> I just hope that we are not going back and force with adding and
> > > >> removing method just because someone needs them somewhere.
> > > >> For now, I think adding the getResourceResolver and removing
> > > >> getResourceProvider should be sufficient. I see no real value in adding
> > > >> the listChildren method which is just a shortcut.
> > > >>
> > > >> Carsten
> > > >>
> > > >
> > > >
> > >
> > >
> >
> >
>
Re: [PROPOSAL]: Add Resource.listChildren() method
Posted by Lars Trieloff <la...@trieloff.net>.
Great, thank you.
On Mon, 2008-02-18 at 10:21 +0100, Felix Meschberger wrote:
> Hi,
>
> Am Montag, den 18.02.2008, 09:50 +0100 schrieb Bertrand Delacretaz:
> > On Feb 17, 2008 10:51 PM, Lars Trieloff <la...@trieloff.net> 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 code used in µjax
> > > 2) not colliding with people using node as a variable name inside loops...
> >
> > I agree about adding a "currentNode" variable to the scripting context
> > for all scripting languages, I just created
> > https://issues.apache.org/jira/browse/SLING-252 about this.
> >
> > -Bertrand
>
> An I just committed the fix, I already had in my workspace ;-)
>
> Regards
> Felix
>
Re: [PROPOSAL]: Add Resource.listChildren() method
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Montag, den 18.02.2008, 09:50 +0100 schrieb Bertrand Delacretaz:
> On Feb 17, 2008 10:51 PM, Lars Trieloff <la...@trieloff.net> 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 code used in µjax
> > 2) not colliding with people using node as a variable name inside loops...
>
> I agree about adding a "currentNode" variable to the scripting context
> for all scripting languages, I just created
> https://issues.apache.org/jira/browse/SLING-252 about this.
>
> -Bertrand
An I just committed the fix, I already had in my workspace ;-)
Regards
Felix
Re: [PROPOSAL]: Add Resource.listChildren() method
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Feb 17, 2008 10:51 PM, Lars Trieloff <la...@trieloff.net> 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 code used in µjax
> 2) not colliding with people using node as a variable name inside loops...
I agree about adding a "currentNode" variable to the scripting context
for all scripting languages, I just created
https://issues.apache.org/jira/browse/SLING-252 about this.
-Bertrand
Re: [PROPOSAL]: Add Resource.listChildren() method
Posted by Lars Trieloff <la...@trieloff.net>.
Hi Carsten, 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 code used in µjax
2) not colliding with people using node as a variable name inside loops
If I remember correctly, Michael might have a patch for this.
regards,
Lars
>
>
> Now, coming back to the issue which started this, I can only repeat
> what I said several weeks (or is it months?) ago: why not adding a
> "node" variable to the available variables of the script?
>
> Then you can simply do a:
>
> if ( node != null ) {
> node.getNodes();
> // do whatever you want with your node
> } else {
> // well, what do you want to do here?
> }
>
> Carsten
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
--
Lars Trieloff
lars@trieloff.net
http://weblogs.goshaky.com/weblogs/lars
Re: [PROPOSAL]: Add Resource.listChildren() method
Posted by Carsten Ziegeler <cz...@apache.org>.
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 abstraction
> from Node but now that we have the abstraction I think we should
> even think of Resources that do not even the concept of a hierarchy.
Exactly :) We should not try to add all stuff we know from jcr to the
resource interface. Therefore things like listChildren should not be
part of Resource.
>
> (2) I would really like to table the sling API discussions for a while
> and let us all gather some experience with what we have before we
> we start modifying the API. From my personal perspective the
> constant change in the sling API is the biggest problem for the
> few early adopters we have.
>
Big +1
Now, coming back to the issue which started this, I can only repeat what
I said several weeks (or is it months?) ago: why not adding a "node"
variable to the available variables of the script?
Then you can simply do a:
if ( node != null ) {
node.getNodes();
// do whatever you want with your node
} else {
// well, what do you want to do here?
}
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [PROPOSAL]: Add Resource.listChildren() method
Posted by David Nuescheler <da...@day.com>.
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 that we have the abstraction I think we should
even think of Resources that do not even the concept of a hierarchy.
(2) I would really like to table the sling API discussions for a while
and let us all gather some experience with what we have before we
we start modifying the API. From my personal perspective the
constant change in the sling API is the biggest problem for the
few early adopters we have.
just my two cents...
regards,
david
On 2/15/08, Lars Trieloff <la...@trieloff.net> wrote:
> 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 the listChildren() method in a
> clean way, but we should also keep in mind that some languages we
> support do not have a concept of methods alltogether (Javascript,
> Velocity, Freemarker), some are dynamically typed and some are untyped.
>
> By disregarding this fact we create a cumbersome API that feels like the
> DOM API (that was designed to be language-independent and lead to
> implementations like DOM4j or JDOM that fit better to the concepts of
> the programming language environment)
>
> To sum it up: When implementing scripting support, we should allow the
> scriptingengine to add additional convenience accessors and type
> conversions, but we should not implement some concepts (like
> listChildren()) exclusively for one language.
>
> regards,
>
>
> Lars
>
>
> On Wed, 2008-02-13 at 09:42 +0100, Carsten Ziegeler wrote:
> > 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 objects that
> > other language do not provide. This will cause problems over time.
> >
> > 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:
> > resource.getResourceResolver().listChildren(resource)
> > you use
> > request.getResourceResolver().listChildren(resource)
> > which frees us from passing the resource resolver to the providers.
> > And it's even much cleaner as a resource does not need to know anything
> > about the resource resolver.
> >
> > I don't think that going this clean api way :) is too much to type for
> > all our script fans here. Assuming that you iterate over children once
> > in a script, you have to type approx. 30 more characters - compared to
> > the overall size of a script its negletable :)
> > Ok, more seriously, this gives us well defined
> >
> > Felix Meschberger wrote:
> > > 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 Node or
> > > Property or an OSGi Bundle resource or an OS filesystem file.
> > > ResourceResolver - The object providing access to Resource instances
> > > from the
> > > application context. The ResourceResolver represents the
> > > external view of
> > > the Resource tree.
> > > ResourceProvider - The object capable of representing certain data as
> > > Resource
> > > objects.
> > >
> > > The ResourceResolver interface is typically implemented once. It
> > > incorporates the logic of dealing with multiple ResourceProvider
> > > services. ResourceProvider instances may be provided by multiple parties
> > > outside of the scope of the ResourceResolver. The ResourceProvider
> > > instances are the factories of Resource objects: The ResourceResolver
> > > asks the ResourceProvider for the creation of Resource objects. That is,
> > > Resource objects are created under the auspices of the ResourceProvider
> > > and not of the ResourceResolver.
> > >
> > > What this means is, that Resource objects have absolutely no means of
> > > accessing the mechanism of how a ResourceResolver uses ResourceProvider
> > > services to find and create Resource objects. Consequently, the Resource
> > > cannot list children and cannot access relative resources.
> > >
> > > Therefore I have to revert and agree with Carsten, that any such child
> > > and relative resource accessor methods must be provided by the
> > > ResourceResolver. Any such API on the Resource interface may always only
> > > be defined in terms of "implemented by calling the respective methods on
> > > the ResourceResolver object". Thus defining such an API prescribes an
> > > actual implementation, which is not the best of all things to be done by
> > > an API ;-) Unless we define Resource as an abstract class with child and
> > > relative resource accessor methods already implemented.
> > >
> > > Undisputed is the fact, that the Resource should have a link to the
> > > ResourceResolver and not to the ResourceProvider. In this respect, the
> > > ResourceProvider interface will have to be enhanced to take the
> > > ResourceResolver asking for a Resource from the ResourceProvider.
> > >
> > > Remains the question of whether we actually should provide additional
> > > public methods and properties on an interface in a single scripting
> > > language which is not available in any other context. In other words: Is
> > > it ok to have a JavaScript "Resource" host object with a "children"
> > > property not matched by a respective Resource.getChildren() method ?
> > > Wouldn't this be too confusing ?
> > >
> > > Regards
> > > Felix
> > >
> > > Am Montag, den 11.02.2008, 09:11 +0100 schrieb Carsten Ziegeler:
> > >> 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 migrating
> > >>> such code to e.g. Java or trying to create similar code in other
> > >>> languages will create tons of issues.
> > >>>
> > >>> In addition, this implementation does not actually work, because it only
> > >>> considers children of the current resource's ResourceProvider neglecting
> > >>> any other ResourceProviders which might have "children" to the resource.
> > >>>
> > >>> I understand, that it is cumbersome to revert to the ResourceResolver to
> > >>> list the children of a resource - not just in JavaScript. So I would
> > >>> like to propose these changes to the Resource interface:
> > >>>
> > >>>
> > >>> Add Methods:
> > >>> Iterator<Resource> listChildren(); // equivalent to
> > >>> getResourceResolver().listChildren()
> > >>> ResourceResolver getResourceResolver();
> > >>>
> > >>> Remove Method:
> > >>> ResourceProvider getResourceProvider(); // replaced by
> > >>> getResourceResolver()
> > >>>
> > >> I'm not against these changes, but I think we discussed this some months
> > >> ago when we
> > >> discussed the Resource interface. And there were some arguments against
> > >> doing this (which I can't remember and haven't looked up).
> > >> I just hope that we are not going back and force with adding and
> > >> removing method just because someone needs them somewhere.
> > >> For now, I think adding the getResourceResolver and removing
> > >> getResourceProvider should be sufficient. I see no real value in adding
> > >> the listChildren method which is just a shortcut.
> > >>
> > >> Carsten
> > >>
> > >
> > >
> >
> >
>
>
Re: [PROPOSAL]: Add Resource.listChildren() method
Posted by Lars Trieloff <la...@trieloff.net>.
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 the listChildren() method in a
clean way, but we should also keep in mind that some languages we
support do not have a concept of methods alltogether (Javascript,
Velocity, Freemarker), some are dynamically typed and some are untyped.
By disregarding this fact we create a cumbersome API that feels like the
DOM API (that was designed to be language-independent and lead to
implementations like DOM4j or JDOM that fit better to the concepts of
the programming language environment)
To sum it up: When implementing scripting support, we should allow the
scriptingengine to add additional convenience accessors and type
conversions, but we should not implement some concepts (like
listChildren()) exclusively for one language.
regards,
Lars
On Wed, 2008-02-13 at 09:42 +0100, Carsten Ziegeler wrote:
> 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 objects that
> other language do not provide. This will cause problems over time.
>
> 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:
> resource.getResourceResolver().listChildren(resource)
> you use
> request.getResourceResolver().listChildren(resource)
> which frees us from passing the resource resolver to the providers.
> And it's even much cleaner as a resource does not need to know anything
> about the resource resolver.
>
> I don't think that going this clean api way :) is too much to type for
> all our script fans here. Assuming that you iterate over children once
> in a script, you have to type approx. 30 more characters - compared to
> the overall size of a script its negletable :)
> Ok, more seriously, this gives us well defined
>
> Felix Meschberger wrote:
> > 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 Node or
> > Property or an OSGi Bundle resource or an OS filesystem file.
> > ResourceResolver - The object providing access to Resource instances
> > from the
> > application context. The ResourceResolver represents the
> > external view of
> > the Resource tree.
> > ResourceProvider - The object capable of representing certain data as
> > Resource
> > objects.
> >
> > The ResourceResolver interface is typically implemented once. It
> > incorporates the logic of dealing with multiple ResourceProvider
> > services. ResourceProvider instances may be provided by multiple parties
> > outside of the scope of the ResourceResolver. The ResourceProvider
> > instances are the factories of Resource objects: The ResourceResolver
> > asks the ResourceProvider for the creation of Resource objects. That is,
> > Resource objects are created under the auspices of the ResourceProvider
> > and not of the ResourceResolver.
> >
> > What this means is, that Resource objects have absolutely no means of
> > accessing the mechanism of how a ResourceResolver uses ResourceProvider
> > services to find and create Resource objects. Consequently, the Resource
> > cannot list children and cannot access relative resources.
> >
> > Therefore I have to revert and agree with Carsten, that any such child
> > and relative resource accessor methods must be provided by the
> > ResourceResolver. Any such API on the Resource interface may always only
> > be defined in terms of "implemented by calling the respective methods on
> > the ResourceResolver object". Thus defining such an API prescribes an
> > actual implementation, which is not the best of all things to be done by
> > an API ;-) Unless we define Resource as an abstract class with child and
> > relative resource accessor methods already implemented.
> >
> > Undisputed is the fact, that the Resource should have a link to the
> > ResourceResolver and not to the ResourceProvider. In this respect, the
> > ResourceProvider interface will have to be enhanced to take the
> > ResourceResolver asking for a Resource from the ResourceProvider.
> >
> > Remains the question of whether we actually should provide additional
> > public methods and properties on an interface in a single scripting
> > language which is not available in any other context. In other words: Is
> > it ok to have a JavaScript "Resource" host object with a "children"
> > property not matched by a respective Resource.getChildren() method ?
> > Wouldn't this be too confusing ?
> >
> > Regards
> > Felix
> >
> > Am Montag, den 11.02.2008, 09:11 +0100 schrieb Carsten Ziegeler:
> >> 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 migrating
> >>> such code to e.g. Java or trying to create similar code in other
> >>> languages will create tons of issues.
> >>>
> >>> In addition, this implementation does not actually work, because it only
> >>> considers children of the current resource's ResourceProvider neglecting
> >>> any other ResourceProviders which might have "children" to the resource.
> >>>
> >>> I understand, that it is cumbersome to revert to the ResourceResolver to
> >>> list the children of a resource - not just in JavaScript. So I would
> >>> like to propose these changes to the Resource interface:
> >>>
> >>>
> >>> Add Methods:
> >>> Iterator<Resource> listChildren(); // equivalent to
> >>> getResourceResolver().listChildren()
> >>> ResourceResolver getResourceResolver();
> >>>
> >>> Remove Method:
> >>> ResourceProvider getResourceProvider(); // replaced by
> >>> getResourceResolver()
> >>>
> >> I'm not against these changes, but I think we discussed this some months
> >> ago when we
> >> discussed the Resource interface. And there were some arguments against
> >> doing this (which I can't remember and haven't looked up).
> >> I just hope that we are not going back and force with adding and
> >> removing method just because someone needs them somewhere.
> >> For now, I think adding the getResourceResolver and removing
> >> getResourceProvider should be sufficient. I see no real value in adding
> >> the listChildren method which is just a shortcut.
> >>
> >> Carsten
> >>
> >
> >
>
>
Re: [PROPOSAL]: Add Resource.listChildren() method
Posted by Carsten Ziegeler <cz...@apache.org>.
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 objects that
other language do not provide. This will cause problems over time.
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:
resource.getResourceResolver().listChildren(resource)
you use
request.getResourceResolver().listChildren(resource)
which frees us from passing the resource resolver to the providers.
And it's even much cleaner as a resource does not need to know anything
about the resource resolver.
I don't think that going this clean api way :) is too much to type for
all our script fans here. Assuming that you iterate over children once
in a script, you have to type approx. 30 more characters - compared to
the overall size of a script its negletable :)
Ok, more seriously, this gives us well defined
Felix Meschberger wrote:
> 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 Node or
> Property or an OSGi Bundle resource or an OS filesystem file.
> ResourceResolver - The object providing access to Resource instances
> from the
> application context. The ResourceResolver represents the
> external view of
> the Resource tree.
> ResourceProvider - The object capable of representing certain data as
> Resource
> objects.
>
> The ResourceResolver interface is typically implemented once. It
> incorporates the logic of dealing with multiple ResourceProvider
> services. ResourceProvider instances may be provided by multiple parties
> outside of the scope of the ResourceResolver. The ResourceProvider
> instances are the factories of Resource objects: The ResourceResolver
> asks the ResourceProvider for the creation of Resource objects. That is,
> Resource objects are created under the auspices of the ResourceProvider
> and not of the ResourceResolver.
>
> What this means is, that Resource objects have absolutely no means of
> accessing the mechanism of how a ResourceResolver uses ResourceProvider
> services to find and create Resource objects. Consequently, the Resource
> cannot list children and cannot access relative resources.
>
> Therefore I have to revert and agree with Carsten, that any such child
> and relative resource accessor methods must be provided by the
> ResourceResolver. Any such API on the Resource interface may always only
> be defined in terms of "implemented by calling the respective methods on
> the ResourceResolver object". Thus defining such an API prescribes an
> actual implementation, which is not the best of all things to be done by
> an API ;-) Unless we define Resource as an abstract class with child and
> relative resource accessor methods already implemented.
>
> Undisputed is the fact, that the Resource should have a link to the
> ResourceResolver and not to the ResourceProvider. In this respect, the
> ResourceProvider interface will have to be enhanced to take the
> ResourceResolver asking for a Resource from the ResourceProvider.
>
> Remains the question of whether we actually should provide additional
> public methods and properties on an interface in a single scripting
> language which is not available in any other context. In other words: Is
> it ok to have a JavaScript "Resource" host object with a "children"
> property not matched by a respective Resource.getChildren() method ?
> Wouldn't this be too confusing ?
>
> Regards
> Felix
>
> Am Montag, den 11.02.2008, 09:11 +0100 schrieb Carsten Ziegeler:
>> 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 migrating
>>> such code to e.g. Java or trying to create similar code in other
>>> languages will create tons of issues.
>>>
>>> In addition, this implementation does not actually work, because it only
>>> considers children of the current resource's ResourceProvider neglecting
>>> any other ResourceProviders which might have "children" to the resource.
>>>
>>> I understand, that it is cumbersome to revert to the ResourceResolver to
>>> list the children of a resource - not just in JavaScript. So I would
>>> like to propose these changes to the Resource interface:
>>>
>>>
>>> Add Methods:
>>> Iterator<Resource> listChildren(); // equivalent to
>>> getResourceResolver().listChildren()
>>> ResourceResolver getResourceResolver();
>>>
>>> Remove Method:
>>> ResourceProvider getResourceProvider(); // replaced by
>>> getResourceResolver()
>>>
>> I'm not against these changes, but I think we discussed this some months
>> ago when we
>> discussed the Resource interface. And there were some arguments against
>> doing this (which I can't remember and haven't looked up).
>> I just hope that we are not going back and force with adding and
>> removing method just because someone needs them somewhere.
>> For now, I think adding the getResourceResolver and removing
>> getResourceProvider should be sufficient. I see no real value in adding
>> the listChildren method which is just a shortcut.
>>
>> Carsten
>>
>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: [PROPOSAL]: Add Resource.listChildren() method
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Feb 13, 2008 9:25 AM, Felix Meschberger <fm...@gmail.com> wrote:
> ...Undisputed is the fact, that the Resource should have a link to the
> ResourceResolver and not to the ResourceProvider....
Agreed, from a scripting point of view I think it's perfectly acceptable to have
resource.resolver.listChildren()
instead of the resource.listChildren that I introduced last week. It's
a good thing to make people aware of the ResourceResolver.
> ...Remains the question of whether we actually should provide additional
> public methods and properties on an interface in a single scripting
> language which is not available in any other context....
I agree that we should not do this, i.e. resource.resolver should map
to a java Resource.getResourceResolver() method, so that all scripting
environments use the same underlying object model.
-Bertrand
Re: [PROPOSAL]: Add Resource.listChildren() method
Posted by Carsten Ziegeler <cz...@apache.org>.
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 objects that
other language do not provide. This will cause problems over time.
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:
resource.getResourceResolver().listChildren(resource)
you use
request.getResourceResolver().listChildren(resource)
which frees us from passing the resource resolver to the providers.
And it's even much cleaner as a resource does not need to know anything
about the resource resolver.
I don't think that going this clean api way :) is too much to type for
all our script fans here. Assuming that you iterate over children once
in a script, you have to type approx. 30 more characters - compared to
the overall size of a script its negletable :)
Ok, more seriously, this gives us a well defined api and contracts:
- How to you get resources? using the resource resolver
- How to you get the resource resolver? from the request
There are no other ways and no additional magic.
Nice and clean imho
Carsten
Felix Meschberger wrote:
> 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 Node or
> Property or an OSGi Bundle resource or an OS filesystem file.
> ResourceResolver - The object providing access to Resource instances
> from the
> application context. The ResourceResolver represents the
> external view of
> the Resource tree.
> ResourceProvider - The object capable of representing certain data as
> Resource
> objects.
>
> The ResourceResolver interface is typically implemented once. It
> incorporates the logic of dealing with multiple ResourceProvider
> services. ResourceProvider instances may be provided by multiple parties
> outside of the scope of the ResourceResolver. The ResourceProvider
> instances are the factories of Resource objects: The ResourceResolver
> asks the ResourceProvider for the creation of Resource objects. That is,
> Resource objects are created under the auspices of the ResourceProvider
> and not of the ResourceResolver.
>
> What this means is, that Resource objects have absolutely no means of
> accessing the mechanism of how a ResourceResolver uses ResourceProvider
> services to find and create Resource objects. Consequently, the Resource
> cannot list children and cannot access relative resources.
>
> Therefore I have to revert and agree with Carsten, that any such child
> and relative resource accessor methods must be provided by the
> ResourceResolver. Any such API on the Resource interface may always only
> be defined in terms of "implemented by calling the respective methods on
> the ResourceResolver object". Thus defining such an API prescribes an
> actual implementation, which is not the best of all things to be done by
> an API ;-) Unless we define Resource as an abstract class with child and
> relative resource accessor methods already implemented.
>
> Undisputed is the fact, that the Resource should have a link to the
> ResourceResolver and not to the ResourceProvider. In this respect, the
> ResourceProvider interface will have to be enhanced to take the
> ResourceResolver asking for a Resource from the ResourceProvider.
>
> Remains the question of whether we actually should provide additional
> public methods and properties on an interface in a single scripting
> language which is not available in any other context. In other words: Is
> it ok to have a JavaScript "Resource" host object with a "children"
> property not matched by a respective Resource.getChildren() method ?
> Wouldn't this be too confusing ?
>
> Regards
> Felix
>
> Am Montag, den 11.02.2008, 09:11 +0100 schrieb Carsten Ziegeler:
>> 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 migrating
>>> such code to e.g. Java or trying to create similar code in other
>>> languages will create tons of issues.
>>>
>>> In addition, this implementation does not actually work, because it only
>>> considers children of the current resource's ResourceProvider neglecting
>>> any other ResourceProviders which might have "children" to the resource.
>>>
>>> I understand, that it is cumbersome to revert to the ResourceResolver to
>>> list the children of a resource - not just in JavaScript. So I would
>>> like to propose these changes to the Resource interface:
>>>
>>>
>>> Add Methods:
>>> Iterator<Resource> listChildren(); // equivalent to
>>> getResourceResolver().listChildren()
>>> ResourceResolver getResourceResolver();
>>>
>>> Remove Method:
>>> ResourceProvider getResourceProvider(); // replaced by
>>> getResourceResolver()
>>>
>> I'm not against these changes, but I think we discussed this some months
>> ago when we
>> discussed the Resource interface. And there were some arguments against
>> doing this (which I can't remember and haven't looked up).
>> I just hope that we are not going back and force with adding and
>> removing method just because someone needs them somewhere.
>> For now, I think adding the getResourceResolver and removing
>> getResourceProvider should be sufficient. I see no real value in adding
>> the listChildren method which is just a shortcut.
>>
>> Carsten
>>
>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: [PROPOSAL]: Add Resource.listChildren() method
Posted by Felix Meschberger <fm...@gmail.com>.
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 Node or
Property or an OSGi Bundle resource or an OS filesystem file.
ResourceResolver - The object providing access to Resource instances
from the
application context. The ResourceResolver represents the
external view of
the Resource tree.
ResourceProvider - The object capable of representing certain data as
Resource
objects.
The ResourceResolver interface is typically implemented once. It
incorporates the logic of dealing with multiple ResourceProvider
services. ResourceProvider instances may be provided by multiple parties
outside of the scope of the ResourceResolver. The ResourceProvider
instances are the factories of Resource objects: The ResourceResolver
asks the ResourceProvider for the creation of Resource objects. That is,
Resource objects are created under the auspices of the ResourceProvider
and not of the ResourceResolver.
What this means is, that Resource objects have absolutely no means of
accessing the mechanism of how a ResourceResolver uses ResourceProvider
services to find and create Resource objects. Consequently, the Resource
cannot list children and cannot access relative resources.
Therefore I have to revert and agree with Carsten, that any such child
and relative resource accessor methods must be provided by the
ResourceResolver. Any such API on the Resource interface may always only
be defined in terms of "implemented by calling the respective methods on
the ResourceResolver object". Thus defining such an API prescribes an
actual implementation, which is not the best of all things to be done by
an API ;-) Unless we define Resource as an abstract class with child and
relative resource accessor methods already implemented.
Undisputed is the fact, that the Resource should have a link to the
ResourceResolver and not to the ResourceProvider. In this respect, the
ResourceProvider interface will have to be enhanced to take the
ResourceResolver asking for a Resource from the ResourceProvider.
Remains the question of whether we actually should provide additional
public methods and properties on an interface in a single scripting
language which is not available in any other context. In other words: Is
it ok to have a JavaScript "Resource" host object with a "children"
property not matched by a respective Resource.getChildren() method ?
Wouldn't this be too confusing ?
Regards
Felix
Am Montag, den 11.02.2008, 09:11 +0100 schrieb Carsten Ziegeler:
> 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 migrating
> > such code to e.g. Java or trying to create similar code in other
> > languages will create tons of issues.
> >
> > In addition, this implementation does not actually work, because it only
> > considers children of the current resource's ResourceProvider neglecting
> > any other ResourceProviders which might have "children" to the resource.
> >
> > I understand, that it is cumbersome to revert to the ResourceResolver to
> > list the children of a resource - not just in JavaScript. So I would
> > like to propose these changes to the Resource interface:
> >
> >
> > Add Methods:
> > Iterator<Resource> listChildren(); // equivalent to
> > getResourceResolver().listChildren()
> > ResourceResolver getResourceResolver();
> >
> > Remove Method:
> > ResourceProvider getResourceProvider(); // replaced by
> > getResourceResolver()
> >
> I'm not against these changes, but I think we discussed this some months
> ago when we
> discussed the Resource interface. And there were some arguments against
> doing this (which I can't remember and haven't looked up).
> I just hope that we are not going back and force with adding and
> removing method just because someone needs them somewhere.
> For now, I think adding the getResourceResolver and removing
> getResourceProvider should be sufficient. I see no real value in adding
> the listChildren method which is just a shortcut.
>
> Carsten
>
Re: [PROPOSAL]: Add Resource.listChildren() method
Posted by Carsten Ziegeler <cz...@apache.org>.
Tobias Bocanegra wrote:
>
> it's just not intuitive, why should one retrieve the resource resolver
> from a resource and then pass in the very same resource again? this is
> so not object oriented.
>
Hmm, I think directly the opposite :) It's the task of the resolver to
resolve the resources and not of a resource. The resource has no
knowledge how to resolve anything. Therefore I still think that the
cleaner solution is to always use the resource resolver for resolving.
But as I said in the first sentence in my last response :) I'm not
against these changes. If you all think that this is the right move,
well let's do it.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [PROPOSAL]: Add Resource.listChildren() method
Posted by Tobias Bocanegra <to...@day.com>.
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 or trying to create similar code in other
> > languages will create tons of issues.
why not then adding it to the Resource api? i think listChildren() and
getChild() are the 2 most used operations on resource when dealing
with hierarchies.
> > In addition, this implementation does not actually work, because it only
> > considers children of the current resource's ResourceProvider neglecting
> > any other ResourceProviders which might have "children" to the resource.
which is probably a very rare case. and i even doubt if it's a good
idea to support this on every level. since you get problems with child
resource ordering.
> > I understand, that it is cumbersome to revert to the ResourceResolver to
> > list the children of a resource - not just in JavaScript. So I would
> > like to propose these changes to the Resource interface:
> >
> >
> > Add Methods:
> > Iterator<Resource> listChildren(); // equivalent to
> > getResourceResolver().listChildren()
> > ResourceResolver getResourceResolver();
> >
> > Remove Method:
> > ResourceProvider getResourceProvider(); // replaced by
> > getResourceResolver()
so this would not allow mixture of resource resolvers, neither. right?
> I'm not against these changes, but I think we discussed this some months
> ago when we
> discussed the Resource interface. And there were some arguments against
> doing this (which I can't remember and haven't looked up).
> I just hope that we are not going back and force with adding and
> removing method just because someone needs them somewhere.
> For now, I think adding the getResourceResolver and removing
> getResourceProvider should be sufficient. I see no real value in adding
> the listChildren method which is just a shortcut.
it's just not intuitive, why should one retrieve the resource resolver
from a resource and then pass in the very same resource again? this is
so not object oriented.
regards, toby
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---