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 > >
