On Nov 18, 2011, at 11:11 AM, Bill Burke wrote:
>
>
> On 11/18/11 10:30 AM, Santiago Pericas-Geertsen wrote:
>>
>> On Nov 18, 2011, at 10:21 AM, Bill Burke wrote:
>>
>>>
>>>
>>> On 11/18/11 10:14 AM, Santiago Pericas-Geertsen wrote:
>>>> Hi Sergey,
>>>>
>>>> It's an interesting observation. However, I think there may be use cases in which you want to stop the chain _without_ producing a response.
>>>>
>>>> Suppose an app has 2 authentication filters (e.g. for different authentication mechanisms it supports): if the first filter authenticates the user, then there's no need to run the next filter but there's also no response to be set. This is why I think there's value in separating continuations from responses.
>>>>
>>>
>>> A filter should not be able to stop the chain unless it is providing a response. How would a filter know whether stopping the chain was correct behavior without full knowledge of the whole filter stack?
>>
>> User defined filters have the least priority in the chain (by default). As a developer, I know which filters I installed, why shouldn't I be able to control the execution of my chain?
>>
>
> Because its really bad programming practice and prone to serious head-scratching errors?
I'm not sure about the bad programming part (this pattern has been uses successfully in other frameworks), but I do agree it can lead to errors. It's extra power with extra responsibility. Having said that, there's always value in simplifying things too, and Sergey's suggestion does get rid of FilterAction.
Any other votes/opinions on the topic?
-- Santiago