Hi Michael, This is of course feasible: Just extend the MicrojaxPostServlet and overwrite the doPost method with your own extensions and register it for the node type you are working on. Another solution would be to implement a servlet Filter to analyze the request input before it even hits the default servlet.
Regards Felix Am Freitag, den 16.11.2007, 11:14 +0100 schrieb Michael Marth: > Hi Felix, > > thanks for your reply. I agree with you that hacking special cases into the > servlet is a no-no. But the servlet is already handling a number of generic, > often required things. How about if the application writer could implement a > POST script that does whatever bizarre logic he wishesAfter execution the > request could be passed on to the MicrojaxPostServlet for further execution > of the generic stuff. As such, application writers would not have to > reinvent the basics but could extend the behaviour. This approach would not > change the microjax protocol either, because the servlet could still receive > the same request. > > WDYT? > > Michael > > On 11/15/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > > > Hi Micheal, > > > > Your are touching a series of points. The main point, if I understand > > correclty, is about scripting any HTTP method not just the GET method. > > This of course part of microsling and has already been. So, as David > > wrote, you could write a POST.xxx script, which handles your post in > > your own format, which you completely define yourself depending on your > > application's need. > > > > As for extending the MicrojaxPostSerlvet: I would not extend it without > > reconsidering the microjax client side. microjax defines a protocol, > > where the MicrojaxPostServlet implements the server side. It would now > > be a very bad idea to hack something into that servlet, which is not > > part of the microjax protocol, just for a very specific use case. > > > > So, I suggest you implement a POST script and handle the post there. > > > > Hope this helps. > > > > Regards > > Felix > > > > Am Mittwoch, den 14.11.2007, 10:16 +0100 schrieb Michael Marth: > > > Hi, > > > > > > I played a bit with microsling's new microjax stuff and would like to > > offer > > > some comments on the MicrojaxPostServlet. As far as I understand this is > > > where my app's POST requests get processed (i.e. this is basically where > > my > > > app can modify the repository). > > > > > > My app got quite far with the request parameters that are currently > > parsed > > > and implemented, but I also hit a wall pretty soon (some use cases that > > are > > > not possible are listed below (*)). Initially, I was planning to raise > > some > > > feature requests for additional request parameters, but I realized that > > the > > > whole architecture in terms of repository writing/modification feels > > wrong > > > to me. Why should my app's repository operations be confined by the > > > currently implemented parameter set? That's what I would like to bring > > up > > > here. > > > > > > I think that the processing of POSTs, i.e. writing into the repository > > > should be scriptable just like the processing of GETs is. This means > > that > > > the MicrojaxPostServlet should not parse hard-coded parameters and do > > some > > > hard-coded stuff with them. It should invoke a script. That script > > should be > > > able to write, delete, modify, etc (e.g. by getting the request and the > > > repository as scriptable objects). > > > > > > AFAIK there is still some filters to be implemented, but IMO that will > > not > > > cut it. I think that the core functionality of repository writing needs > > to > > > be open for the app developer (even if you think of Sling as a > > > "presentation" framework - my simple blogging app has already hit this > > > wall). We could still keep the mechanism right now for very simple cases > > or > > > as a fall-back. > > > > > > WDYT? > > > > > > Cheers > > > Michael > > > > > > > > > (*) In order to not get too esoteric, here's some use cases that bugged > > me > > > (I am aware that there are workarounds for these): > > > My example app is a blogging application and I would like blog readers > > to be > > > able to leave comments. The problems are: > > > - the comments shall have a date. Currently, I need to set the date in > > the > > > browser and pass it along as a request parameter. What I would really > > like > > > is to set this date on the server, i.e. add a custom property before the > > > node gets written > > > (I am aware that I could use Repository Observers to get this done but > > do > > > not I want to write Java code for this) > > > - the comments shall be checked for Spam before they are written. > > > Especially, comments that contain links shall be get a special property > > > "suspicious" > > > - I would like to moderate or delete comments in a batch, i.e. modify > > > multiple nodes in one request > > > >