Hi,
Carsten Ziegeler schrieb:
Felix Meschberger wrote:
This in fact applies not just to post processing but also to
pre-processing. In fact, we might emply the same basic mechanism for
pre- and post-processing as we envision for servlet filters:
Registered services are entered as pre/post-processor resources into
the virtual resource tree at a pre-defined location.
pre/post-processor scripts might be located at the same place and
selected for execution.
>
You mean registering all services in the resource tree even the Java
based ones?
Yes, the pre/post-processor services would be "virtual" resources whose
resource type is just "itself", much like for servlet resources.
Nevertheless, I would keep on seing the SlingPostServlet as the
controller and _not_ any script handling post requests -- something
like "don't call us, we'll call you".
Yes, definitly.
For now I have the problem of seeing a nice way to actually call the
script. Do we envision that the script contains some defined methods?
No, I think we would provide the "parameters" as global, bound
variables. This is comparable to the DefaultSlingScript we use to have
the script as if it would be a servlet.
Taking the analogy further, it would be like this: The processor
resolver finds the pre/post-processor resources and adapts them to
PreProcessor or PostProcessor. The services registered as virtual
resources just return themselves. For the scripts there would be a an
adapter factory, which adapts the pre/post-processor scripts to the
PreProcessor or PostProcessor by creating a PreProcessorScript (or
PostProcessorScript) instance wrapping the script.
But we should keep the ball low for now and just do the plain old OSGi
service stuff: just have the processors registered as services and the
SlingPostServlets uses these services.
Regards
Felix
