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.
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
--
Carsten Ziegeler
[EMAIL PROTECTED]