Hi, I'm mostly done with a first highly experimental server plugin implementation.
I would like to hear your opinion about the order of plugin filters call. The current implementation is the "Observer" pattern described in the RFC, together with Martin Dobias we decided to start with two filter hooks: * requestReady * responseReady having the opportunity to alter the parameters (coming from the query string or soap or whatever) before entering the core services switch, we can effectively skip it over completely in case of need. For this reason (and because a raised exception is stored in the request), the exceptionRaised hook is not necessary anymore. Plugin filters can be optionally ordered by a "priority" (defaults to 0) and filters with lower priority will run first. Beside the fact that a filter is not forced to implement both hooks (and hence it can decide to have requestReady and responseReady filters with arbitrary priority), my question is if is it better to invert the priority order on responseReady hook. This is a common pattern in web applications, where filters are creating kind of "onion" wrappers or "middleware" (for example in Django framework). So, for instance registerFilter( filter1, 200) # priority 200 registerFilter( filter2, 100) # priority 100 will result in the following calls: filter2.requestReady filter1.requestReady core services (if matches) filter1.responseReady filter2.responseReady I prefer the solution above to the same priority ordering on both hooks: filter2.requestReady filter1.requestReady core services (if matches) filter2.responseReady filter1.responseReady -- Alessandro Pasotti w3: www.itopen.it _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
