Ah ok thanks, wasn't really sure about that due to the alternative resolve signature with request but I should have read the classdescription which is pretty clear.
So +1 from my side as well. Best regards Dominik Am 16.12.2013 21:38 schrieb "Alexander Klimetschek" <aklim...@adobe.com>: > On 16.12.2013, at 04:38, Dominik Süß <dominik.su...@gmail.com> wrote: > > > There is currently a gap between the behavior of .resolve() and > .getResource() > > where getResource would return null and .resolve() should return a > > NonExistingResource. I'm pretty sure there is a reason for that, but I > > couldn't find it. > > Oh, yes, there is a good reason for that: > > - resolve() is used for request processing, where it is necessary to > handle the non-existing case with the special sling:nonexisting resource > type and the original path info > - getResource() is the more "raw" access, similar to JCR Session.getNode() > (*) > > Applications would always use getResource() and handle the null check. > resolve() is mostly only for the sling engine, or if you have some more > complex internal forwarding etc. that requires to replicate Sling's > resolution behavior. > > (*) yes, getNode() throws an exception, but that's similar to returning > null compared to returning a special NonExistingResource object > > Cheers, > Alex > >
