Hi Dominik, Wouldn't a ResourceDecorator be a better solution in those case? I.e. if a resource is of type app/foo and is under /content/bar, decorate the resource to app/bar ?
The fact that you can register servlets by path should *not* in my opinion be a reason to extend behavior-by-path to other parts of Sling. Regards, Justin On Wed, Jul 3, 2013 at 8:22 AM, Dominik Süß <dominik.su...@gmail.com> wrote: > Hi Bertrand, > > while I agree that paths should not drive the app they might build a scope > for the logic, since the content is organized in a tree structure and not > in by it's resourceType hierarchy, Therefore you often do have pathspecific > operations (just think of workflows and workflowlaunchers in CQ). Or to > come up with another scenario. > Changing resourceTypes depending on the location of the same data on the > other hand would be redundant information. > > So - the main Driver should be the resourceType is what is defining the > behavior of a component while the contentpath in my eyes could act as > restricting criteria. > > WDYT? > > > On Wed, Jul 3, 2013 at 1:22 PM, Bertrand Delacretaz > <bdelacre...@apache.org>wrote: > > > Hi, > > > > On Wed, Jul 3, 2013 at 12:55 PM, Dominik Süß <dominik.su...@gmail.com> > > wrote: > > > ...why do you think registering logic by path is bad. Especially if I > > look at > > > potential for multitenantsupport it would be great to be able to > register > > > postbehavior that is tenantspecific. And the tenantsupport of Sling is > > > completely based on paths.... > > > > In general we want people to get away from the notion that paths drive > > your app, it should be resource types that do. > > > > Also, the problem with paths is that they are usually hidden in code, > > whereas resource types are transparently exposed in the content. > > > > For the POST handling, we could very well take the resource type of > > the parent/ancestors into account, instead of relying on paths. > > > > -Bertrand > > >
