Pill, Juergen wrote: > 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. >
I can write it. Where should I put it ? howto-contentInterceptors.html ? jp > > 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]> > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
