Hi Paul, Thanks for clearly exposing your views. One use case that your approach doesn't seem to cover is the mixing of Routers with Filters.
I think it comes down to a choice between an external description of the processing flow and an inlined one (as in Restlet API). To me the second approach is more natural because you can literally follow the processing chain instead of having to go back and forth between a controller/description and the controlled nodes. Maybe we could at some point consider both approaches. Feel free to create a RFE if you want this to be tracked/reconsidered for a future version 2.0. Any other opinion? Best regards, Jerome > -----Message d'origine----- > De : Paul J. Lucas [mailto:[EMAIL PROTECTED] > Envoyé : dimanche 13 janvier 2008 20:10 > À : discuss@restlet.tigris.org > Objet : Re: Aborting request in Filter > > 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." > >
