I thought a bit about that idea and still have some doubts. If we move the whole processing into interceptors we will end up with "system" interceptors that must run on the beginning and with "user" related/developed interceptors. And either we allow create custom stacks and mix the "system" interceptors with the "user" interceptors (user will be able to create stack without the "system" interceptors) or we will have to fasten the "system" interceptors to be always run and allow user only play with the "user" interceptors.
Basically I like the idea with moving as much as possible "system" logic into interceptors - this allows users change flow whenever they want. But to do it and not to create monsters like ParametersInterceptor we must introduce some kind of an interceptor inner dependency flow - I mean interceptors can define pre/post-conditions for other interceptors (ie. cannot run ParametersInterceptor if SanityCheckInterceptor wasn't executed and so on). It can be as simple as defining what interceptor names were already processed. Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
