Hi,
Bertrand Delacretaz schrieb:
On Tue, Jul 22, 2008 at 12:12 PM, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
Michael Marth wrote:
... <%
changes = Sling.defaultPOSTBehaviour();
// do some more
%>...
...This is indeed an interesting topic, but atm I don't see a way how to
achieve this in an easy manner...
How about having the PostServlet lookup scripts using a special method
name for this?
For example, /apps/foo/AFTER_POST.esp could be the PostServlet
postprocessor for the foo resource type.
The PostServlet would then
1) Lookup the script as above, using the standard ScriptResolver, and if found:
2) Put the list of changes in the script context
3) Execute the script, which might modify the list of changes
4) Save the resulting changes, or handle an OperationVetoException, etc.
Generalizing such a "script hook for standard operations" mechanism
sounds useful, assuming there's a way (probably via the
RequestProgressTracker) to clearly see what's happening.
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.
This makes looking up the processors are very simple resource tree
access operation and calling the filters in succession.
[ thinking further, we might even introduce helper/utility code to
implement such scripting functionality for others to use besides servlet
filters and pre/post-processing ]
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".
WDYT ?
Regards
Felix
-Bertrand
