Hi Felix, implementing a servlet or a servlet filter takes me back to coding Java. It is my understanding that at least microsling (not necessarily Sling) should allow me to code JCR-based web apps in scripting languages (ie. that my scripts are able to write into the repository).
WDYT? What should microsling include? Michael On 11/16/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > 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 > > > > > > > >
