Hi Michael, Am Donnerstag, den 20.12.2007, 17:07 +0100 schrieb Michael Marth: > at the moment one can only use the microjax post servlet in an > all-or-nothing way. This means that my app needs to decide: I either send > POSTs to the microjax servlet and that's all there is. Or I implement > POST.esp which means I can do all I wish to do, but I have to replicate all > of microjax's servlet functionality (in terms of writing to the repository).
Yes, and this will not change most probably. > I would really like to have a mechanism to mix this, i.e. to extend the > microjax servlet with custom logic. And there is actually a real-world use > case for it: Spam filtering. Right now I had to revert to a Java servlet to > do this (because I did not want to implement POST.esp). IMO it would be > great if we had something like "filters" or "pipelines" or whatever you want > to call it in microsling. First things first: microsling is non-extensible, non-configurable and fixed. If you want to extend microsling, you have to write code and rebuild microsling. This has always been the case with microsling and this is the big plus of microsling. BUT, ... We are currently working on recreating microsling (see Bertrand's thread on µsling 2.0 requirements). The result will be that most probably microsling will end up as a precanned Sling, which provides the same extensibility features under the hood as Sling, yet they are not made available through the GUI. Back to your problem: What you might want to do, as you said, is SPAM "filtering". So you would implement a Filter, register it with the system and get the raw requests in your hands and can react before the servlet (or script) is even called (well this is not new information, of course ;-) ). Regards Felix
