I have used the ContentInterceptor to provide a document search service. I used JP's initial code. It works great. Currently in the process of integrating it with certain other pieces. I do need to make adjustments to account for JP's latest proposals.
Hope this helps Akil PS Count me as a +1 on all the points below. Thanks. ----- Original Message ----- From: "Christopher Lenz" <[EMAIL PROTECTED]> To: "Slide Developer Discussion" <[EMAIL PROTECTED]> Sent: Friday, April 19, 2002 7:06 AM 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]>
