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
-- 
-----------------------------------------< [EMAIL PROTECTED] >---
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 >---

Reply via email to