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
