On 10/14/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > ...Regarding the resource: I think, we should provide the JCR item to which > the request URL resolved with a proper method, such as "Item getItem();" > and leave the "Object getDate();" method to the object mapping. ..
Fine with me, although this makes the Resource more JCR-specific. But I think we're fine with that. > ...In > addition, I would provide the selectors, extension and suffix in the > Resource, too, as proposed on the Wiki page... I don't like this - I'd much prefer a ParsedRequestPath object, stored in the SlingRequestContext, that's initialized when the Resource is resolved. I don't think extension, selectors and the like belong in the Resource. They describe how the request path was parsed to find the Resource, but they are definitely not part of the resource itself. And I feel it important to keep the Resource interface as small as possible, as it's a central part of microsling - keeping it small helps people focus on what's important. What do you think? Could we put this info somewhere else? > ...Providing the JCR Item and mapped object in the Resource interface > itself would of course stipulate, that microsling (and hence Sling, see > my other posting in this thread) would be based on the repository and/or > mapping and there would be no other source such as the filesystem etc.... Using other data sources would still be possible, in which case Resource.getItem() returns null and Resource.getData() returns the File or whatever object. But I think we all agree that that's not our focus. -Bertrand
