1. Enable ContentInterceptors to be configured via parameters [x] +1. I agree with the change. [ ] +0. I don't care. [ ] -1. I don't agree, because:
2. Add a postRemoveContent() method to ContentInterceptor, to be called when the content of all revisions or one particular revision of a node has been removed from the namespace [x] +1. I agree with the change. [ ] +0. I don't care. [ ] -1. I don't agree, because: 3. Allow the preXXX()/postXXX() methods of ContentInterceptor to throw exceptions, in particular: AccessDeniedException, ObjectNotFoundException, LinkedObjectNotFoundException, ObjectLockedException and ServiceAccessException. This is to allow interceptors to truly intercept content operations, and to not force implementors to "swallow" important errors. [x] +1. I agree with the change. [ ] +0. I don't care. [ ] -1. I don't agree, because: 4. Allow ContentInterceptors to access the namespace via a NamespaceAccessToken to permit operations like logging to the namespace logger etc. [x] +1. I agree with the change, but it gives the interceptors huge control over the Slide datastructures, which might be necessary and OK! [ ] +0. I don't care. [ ] -1. I don't agree, because: 5. Make ContentInterceptor an interface, and provide a basic (mostly empty) implementation as AbstractContentInterceptor, to make the API contract clearer. (*) [x] +1. I agree with the change. [ ] +0. I don't care. [ ] -1. I don't agree, because: 6. To round up the ContentInterceptor interface, also add the methods preRetrieveContent() and preRemoveContent(), so that all event types have pre and post hooks. (*) [x] +1. I agree with the change. [ ] +0. I don't care. [ ] -1. I don't agree, because: 7. Implement the agreed upon changes in the SLIDE_1_0 branch for the upcoming release 1.1.0, as well as in the HEAD branch. [x] +1. I agree with the change. [ ] +0. I don't care. [ ] -1. I don't agree, because: 8. Write documentation (possible the user quota could serve as an example) how to use interceptors. I this documentation I would make people aware of Tomcat 4 filters, for the some applications this might sufficient and more easy to program and use. Best regards Juergen -----Original Message----- From: Christopher Lenz [mailto:[EMAIL PROTECTED]] Sent: Friday, April 19, 2002 14.06 PM To: Slide Developer Discussion Subject: [VOTE] ContentInterceptor API changes Jean-Philippe Courson has provided patches and discussion for making the org.apache.slide.content.ContentInterceptor more usable. As there were never any implementations of that class (at least none that I'm aware of), usability of it's API has not been tested in the real world. Jean-Philippe worked on a UserQuotaContentInterceptor to add support for user- quotas to Slide, based on the ContentInterceptor API. This usage revealed some serious shortcomings of the API that we should fix as soon as possible. As these changes qualify as API changes, I hereby call for a vote to determine agreement/objections in general, as well as opinions on how far the changes should go. Most of the proposed changes have been submitted by Jean-Philippe as patches, and I've reviewed and partially enhanced these patches, as well as incorporated them with my local copy, so there are only yes/don't care/no options in this vote. [apologies in advance if I've missed some formal conventions on votes] 1. Enable ContentInterceptors to be configured via parameters [ ] +1. I agree with the change. [ ] +0. I don't care. [ ] -1. I don't agree, because: 2. Add a postRemoveContent() method to ContentInterceptor, to be called when the content of all revisions or one particular revision of a node has been removed from the namespace [ ] +1. I agree with the change. [ ] +0. I don't care. [ ] -1. I don't agree, because: 3. Allow the preXXX()/postXXX() methods of ContentInterceptor to throw exceptions, in particular: AccessDeniedException, ObjectNotFoundException, LinkedObjectNotFoundException, ObjectLockedException and ServiceAccessException. This is to allow interceptors to truly intercept content operations, and to not force implementors to "swallow" important errors. [ ] +1. I agree with the change. [ ] +0. I don't care. [ ] -1. I don't agree, because: 4. Allow ContentInterceptors to access the namespace via a NamespaceAccessToken to permit operations like logging to the namespace logger etc. [ ] +1. I agree with the change. [ ] +0. I don't care. [ ] -1. I don't agree, because: 5. Make ContentInterceptor an interface, and provide a basic (mostly empty) implementation as AbstractContentInterceptor, to make the API contract clearer. (*) [ ] +1. I agree with the change. [ ] +0. I don't care. [ ] -1. I don't agree, because: 6. To round up the ContentInterceptor interface, also add the methods preRetrieveContent() and preRemoveContent(), so that all event types have pre and post hooks. (*) [ ] +1. I agree with the change. [ ] +0. I don't care. [ ] -1. I don't agree, because: 7. Implement the agreed upon changes in the SLIDE_1_0 branch for the upcoming release 1.1.0, as well as in the HEAD branch. [ ] +1. I agree with the change. [ ] +0. I don't care. [ ] -1. I don't agree, because: (*) The last two points would qualify as API changes that might not be strictly necessary at the moment. But as I stated before, if we're changing the API anyway, we might as well try to get it right. ;-) -chris _______________________________________________ /=/ cmlenz at gmx.de -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
