Hi, Am Dienstag, den 19.02.2008, 17:50 +0100 schrieb Carsten Ziegeler: > The question is which case is the special case? The one with the request > or the one without? Thinking of executing scripts as the task of the > script engine, this is foremost nothing to do with request. So, > personally, I see the request case as the special case :) > > Mocking a request when there is no requests seems to call for trouble at > some point of time. > > So I would add the reader to the bindings and make the request optional.
I definitely agree with Carsten here, that using a MockRequest (and MockResponse btw) is not the best of all solutions. I would rather opt for modifications in the DefaultSlingScript to cope with not being called in a request. Regards Felix > > Carsten > > Alexander Saar wrote: > > I think this would be a suitable solution for our use case and if there are > > other places (like test environments) where is can be used it is probably > > better to invest in such an approach instead of blowing up Slings code base > > with special case implementations. > > > > What do you think would be the best setup approach for such a mock? The > > current SlingHttpRequest implementation requires an instance of RequestData > > which in turn has a reference to the SlingMainServlet. AFAIK I can not > > access the SlingMainServlet from an OSGI service thread. > > > > BTW, the Spring framework has already implemented a MockHttpRequest which > > can be used (or extended or copied in case the dependency to Spring is not > > wanted) for initializing a MockSlingHttpRequest. > > > > Regards, > > Alex > > > > > > On Feb 19, 2008 4:50 PM, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > > > >> Hi, > >> > >> On Feb 19, 2008 3:59 PM, Alexander Saar <[EMAIL PROTECTED]> > >> wrote: > >>> ...We are currently working on a workflow engine on top of Sling and > >> think that > >>> getting a ResourceResolver and executing a script without a request at > >> hand, > >>> eg. within a thread that was triggered by an (job) event, would be cool > >> for > >>> applications that goes beyond plain content delivery.... > >> How about using a "mock" or "internal" request instead of no request? > >> > >> That might make this less of a special case, and having such internal > >> requests might be useful for testing as well. > >> > >> -Bertrand > >> > > > >
