hi Julian On Dec 5, 2014, at 10:31 AM, Julian Sedding <jsedd...@gmail.com> wrote:
> Hi Antonio > > I agree with Justin that we should start with support for resource-types. as said I agree we should have support for both. E.g. sling.filter.pattern, sling.filter.resourceType > > Using path-based restrictions strongly couples configuration to > content, which IMO is not a good practice. At the end of the day is the developer choice to choose the one she needs. In my case for example I cannot use the resource type approach. See also https://issues.apache.org/jira/browse/SLING-3829 regards antonio > > Regards > Julian > > > On Thu, Dec 4, 2014 at 3:54 PM, Antonio Sanso <asa...@adobe.com> wrote: >> thanks Justin for your feedback, >> >> if you would not mind I would try to do the opposite :) >> The only reason is that I have already a Pocs for this that it actually >> requires really few modifications.. (Felix gave me some good hints on how to >> implement it :)) >> It would probably be the same for resource type though :) >> >> regards >> >> antonio >> >> On Dec 4, 2014, at 2:29 PM, Justin Edelson <jus...@justinedelson.com> wrote: >> >>> Hi Antonio, >>> I'd suggest starting with support for resource type and *then* add path >>> support. >>> >>> Justin >>> >>> On Thu, Dec 4, 2014 at 5:46 AM, Antonio Sanso <asa...@adobe.com> wrote: >>>> hi *, >>>> >>>> the current Sling Servlet Filter Support [0] allows to have scope >>>> dependent filter (e.g. REQUEST, INCLUDE, FORWARD, ERROR, COMPONENT). >>>> It would be nice to extend this support to have a specific filter being >>>> taken in consideration only for specific path (adding >>>> sling.filter.pattern) a bit like what currently can be done for Apache >>>> Felix filters. >>>> >>>> WDYT? >>>> >>>> regards >>>> >>>> antonio >>>> >>>> [0] http://sling.apache.org/documentation/the-sling-engine/filters.html >>
