On Wed, 15 Sep 2010 14:57:25 -0300 Fabio Kaminski <fabiokamin...@gmail.com> wrote:
I'm not certain I understand the question, but here goes ... > and at least for data, i thought use something like [input filter -> > handler -> output filter] > > where the input filter receives a formated string and parse into a internal > object struct.. the handler get it > and using a rest mechanism (put,delete,get,post) in the handler.. An input filter doesn't strictly speaking asynchronously with your handler, but conceptually you should think of it as asynchronous. If that fits your application well, go right ahead. Otherwise it's probably going to be easier to do all that within your handler. The exception to that is if you have functionality that becomes re-usable across multiple applications if you put it in a filter. > the handler then call a db api, for the data operation.. and if is something > like get.. the output filter decode our internal object struct into > the formated string.. That sounds like it should be just fine running asynchronously. But using a filter may still call for more groundwork. Ideally you should create a new bucket type for your internal objects to pass them down the chain. > i saw the smart filter, but couldnt fire it.. since i didnt see a example > module using it.. Smart filtering is a matter for configuration. If your application requires the filters, it should probably manage its own configuration. If the filters are optional then by all means leave it to the sysop and recommend using mod_filter in your documentation. -- Nick Kew
