Sorry for not commenting earlier, but....
Anyway, in thinking about this more, I don't think a filter should
have any knowledge of its next filter. When a request is received,
the engine should have a list of filters, i.e., the list itself
should be external to all the filters.
So, currently, you have:
Request -> F1 -> F2 -> ... -> Fn
I would prefer:
Request -> L1<F1> -> L2<F2> -> ... -> Ln<Fn>
where Li is a node in a linked list and the element type of the list
is Filter. However, once you do that, there is no longer a need for
Filter as a separate class: it's just an ordinary Restlet.
Furthermore, whether a filter is "before" or "after" depends only on
where it is in the list and is also not a property of a filter. (If
I wanted a single instance of some filter to be both before and
after, I would simply insert the same instance twice in the list at
different places.)
As for whether to continue upon error, each Restlet, upon insertion
into the list, Restlet could have a method like:
boolean acceptStatus( Status s ) {
return s.isSuccess();
}
Hence, the default would be to abort continuation down the list of
Restlets; however, if a Restlet wants to filter error responses, it
would simply override acceptStatus().
- Paul
On Jan 13, 2008, at 6:51 AM, Jerome Louvel wrote:
Here are the details of the change:
"Filter.beforeHandle() and doHandle() methods can now indicates if the
processing should continue normal, go to the afterHandle() method
directly
or stop immediately.
IMPORTANT NOTE: as it isn't possible to add a return parameter to an
existing method, the change can break existing filters. In this
case, you
just need to return the "CONTINUE" constant from your method and
use "int"
as return parameter."
