Hi, Carsten Ziegeler schrieb: > Vidar Ramdal wrote: >>>> On Fri, Apr 3, 2009 at 1:34 PM, Vidar Ramdal <[email protected]> wrote: >>>>> If I can disregard the points of backwards compatibility and >>>>> documentation for a second, I'd say: I've allways regarded >>>>> NonExistingResource as something of a hack, so I wouldn't mind trying >>>>> to avoid it as much as possible. A null returned when a resource does >>>>> not exist, is certainly easier to grasp for Sling newbies. >>> Alexander Klimetschek schrieb: >>>> Yes, but that's why there are the "getResource()" methods (returning >>>> null) [...] >> On Fri, Apr 3, 2009 at 2:06 PM, Felix Meschberger <[email protected]> wrote: >>> In addition to what Alex said: resolve() is really used by the Sling >>> engine to resolve the URL to a resource. Not returning null here makes >>> the whole processing a lot easier and simpler. [...] >> OK, you convinced me :) >> > I'm in favour of the consistency solution as well; resolve() should > always return a resource.
Ok, we don't have any voices rised in favore of backwards compatibility (except for my slight bias expressed initially). Also, the longer I think of it, the longer I am convinced that in this special case, it might be better to be consistent than to be backwards compatible for the following reason: The difference between resolve and getResource does not seem to be well understood and the resolve method may not be that widely used. Therefore, I think, I am going to be consistent and overthrow the earlier decision to remain backwards compatible. Thanks to all the participants. Regards Felix
