To be honest, for me it currently is the main reason. And the code I'm refering to is owned by a vendor and getting hotfixes can take way to long.
Aditionally right now writting working code is pretty easy but there is no support that helps to write proper skipping (cheap and early) of filters and therefore to write well performing and low impact filters. Giving some OOTB features for such a mighty extensionpoint as Filters seems like a good idea making it easy to write good code. As shown with the ColumnCtrlFilter developers sometimes do simply not realize that they might be way to intrusive because in the current state of applications the filters do no harm. Dominik On Mon, Aug 18, 2014 at 10:25 PM, Carsten Ziegeler <[email protected]> wrote: > Well, so the main argument is badly written code? > > > 2014-08-18 19:35 GMT+02:00 Dominik Süß <[email protected]>: > > > Hi Carsten, > > > > I've played around with filters a lot and the problem with them really is > > that they often have way to much impact and are not constrainted as they > > would need to be. Even those filters skipping often create a lot of > > overhead because they do not skip fast and with cheap evaluations but > > instanciate expensive objects and so on. > > > > Therefore some easy but well performing mechanisms to perform checks in > > first place would really help to avoid uncessary overhead in the request > > livecycle. > > > > Additionally the option to block filters in specific cases without > > deployment would be really something that would help a lot in production > > where waiting for some vendor to fix a filter might take way to long ;) > > > > Cheers > > Dominik > > > > On Mon, Aug 18, 2014 at 1:17 PM, Carsten Ziegeler <[email protected]> > > wrote: > > > > > Do we really really need this? At least path based filtering can be > done > > > with plain servlet filters already. > > > > > > What are the use cases for this? > > > > > > Carsten > > > > > > > > > 2014-08-18 13:07 GMT+02:00 Felix Meschberger <[email protected]>: > > > > > > > Hi > > > > > > > > I am not sure, whether we should go down that route. > > > > > > > > A filter ist something which is a cross-cutting concern that the > > > > application places on the request processing. As such it is > transparent > > > to > > > > the client and it should not be client adressable. Otherwise > unexpected > > > > behaviour is guaranteed. > > > > > > > > Regards > > > > Felix > > > > > > > > Am 18.08.2014 um 11:32 schrieb Bertrand Delacretaz < > > > [email protected] > > > > >: > > > > > > > > > Hi, > > > > > > > > > > On Mon, Aug 18, 2014 at 11:23 AM, Felix Meschberger < > > > [email protected]> > > > > wrote: > > > > >> ... * filter.resourceType: The Filter is only called if the > > > resourceType > > > > >> of the current Resource > (SlingHttpServletRequest.getResource) > > > > >> matches any of the given resource types... > > > > > > > > > > I've long been thinking that we should allow Sling's script/servlet > > > > > resolution logic to be used for more than finding request > processing > > > > > servlets. > > > > > > > > > > Is it something that would apply here? > > > > > > > > > > I'm not sure how that could work, but as an initial experiment we > > > > > could add a SLING-FILTER selector to the request, resolve that to a > > > > > servlet and expect that to be a Filter. And if that works define > that > > > > > better as presented like this it's quite a hack ;-) > > > > > > > > > > -Bertrand > > > > > > > > > > > > > > > > > -- > > > Carsten Ziegeler > > > Adobe Research Switzerland > > > [email protected] > > > > > > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected] >
