Hi,
I have been thinking about this a bit further and have also been
discussing with Carsten.
Given, that the Sling POST Servlets bundle contains interesting stuff
and the SlingPostServlet in the end essentially is just gluing this
stuff together, there might be a solution to the problem.
Even though I said (and still think) that the SlingPostOperation
interface is defined to be able to inject new functionality into the
SlingPostServlet and probably should only be used by the
SlingPostServlet it might be possible to call SlingPostOperation
services from outside the SlingPostServlet.
So what needs to be done ?
The easiest thing would be to just register all predefined operations as
services, which would also be consumed by the SlingPostServlet itself.
Since the SlingPostServlet can register these services itself, there is
no issue for setting these (particularly for the ModifyOperation or the
ImportOperation).
But, if we are at it: How about fixing another issue itching my back
every now and then: The HtmlResponse class is an extremely strange biest
-- and probably not correctly located in the Sling API bundle (from
today's perspective, at least).
So here is my full proposal:
1. Create new response helper classes (replacing HtmlResponse):
AbstractHttpResponse -- help gather changes, status, etc.
and has abstract send method.
HtmlHttpResponse -- implements send method generating HTML
JsonResponse -- implements send method generating JSON
2. Create a new PostOperation interface with a slightly different
API than today's SlingPostOperation:
// the SlingPostProcess[] may be null
void run(SlingHttpServletRequest, AbstractHttpResponse,
SlingPostProcess[])
3. Create an AbstractPostOperation analogous to the
AbstractSlingPostOperation
4. Refactor predefined operations of the Sling POST Servlet bundle
to the new interface and register them as services
5. For backwards compatibility, provide a service proxy for existing
SlingPostOperation services. The SlingPostOperation interface and
AbstractSlingPostOperation abstract class are deprecated.
WDYT ?
Regards
Felix
On 26.08.2010 14:13, Alexander Klimetschek wrote:
> Hi all,
>
> if you have a custom servlet that wants to run Sling's POST servlet
> handling _after_ it has done something, it theoretically could do so
> by getting the required SlingPostOperation and simply run it (just as
> the SlingPostServlet does it).
>
> (The only other way to integrate the POST servlet functionality with
> custom things is to implement a SlingPostProcessor, but this is after
> the fact, and doesn't allow for cases, where your servlet is the
> authority of creating the content that e.g. the modify operation
> should work on.)
>
> However, the standard operations, such as the default ModifyOperation,
> are unfortunately not exposed as services, and are hidden in the
> private export section of the bundle.
>
> I see two solutions:
>
> 1) all built-in SlingPostOperations should be registered as service
> - works fine for Copy, Move, Delete
> - ModifyOperation requires objects passed in its constructor
> + NodeNameGenerator and DateParser:
> their configuration should be moved from the SlingPostServlet component to
> the new ModifyOperation component (only used there anyway)
> + ServletContext:
> required "only" for getting the mime types configured in the servlet
> engine,
> to be used for file uploads; not sure how to solve that (*)
>
> 2) export all *Operation classes from the bundle
> (ie. move them to a new public o.a.sling.servlets.post.operation package)
>
> While 1) seems to be cleaner (not exposing internal implementation),
> 2) is much simpler to do and would also allow to build custom
> operations that extend the existing ones (however, we might not want
> to push that...).
>
> WDYT?
>
> Regards,
> Alex
>
>
> (*) Some ideas:
> - additional mime type config in the ModifyOperation
> - pass ServletContext in new SlingPostOperation.run() method
> - pass ServletContext as request attribute in request given via run() method
>
