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

Reply via email to