Hello Per Kreipke, Sorry, if I had put you on the wrong track.
Yes, in the case of filters you would need to know a lot of the Slide data types in certain application areas. The Domain class is not initialized and (I think) it is hard to have two Slides initialized. If you need too much of Slide, Interceptors may be a lot more useful. Just rewriting urls would have been a very easy use case for filters, but you seem to need more Slide specific functionality. Best regards Juergen -----Original Message----- From: Per Kreipke [mailto:[EMAIL PROTECTED]] Sent: Friday, April 19, 2002 17.14 PM To: Slide Users Mailing List Subject: RE: Callbacks, virtual directories and more Juergen, I've been working hard at making filtering solve the problem I described below but haven't had much success. This also relates to your comment in the thread about voting on the new ContentInterceptor API about letting people know about filters in TC4/Servlet 2.3 as an alternative to the ContentInterceptors. Besides the fact that I can't get servlets plus filters to do what I want, filters are outside the Slide framework instead of inside it. I would hope that the ContentInterceptors know more about the Slide application and resource state than a filter would. E.g. a filter would have to duplicate much of the code needed to resolve a Slide request before then passing info on down the chain. I'd think that ContentInterceptor is easier than Filter for a simple callback mechanism. There's no need to wrap Request and Response objects to map paths, args, etc. There's no need for RequestDispatchers, etc. Per > Juergen > > Did you have a look at the Tomcat 4 filter functionality? > > I have. We just switched to TC4 from 3.X to get at it. However, > I'm not sure > yet how it will be useful. > > - I think filtering could be the place to manage callbacks. I was hoping > that the ContentInterceptor framework would be more extensive and include > other ways to hook into Slide processing from _within_. Otherwise I figure > I'll have to do duplicate the object resolving the Slide webapp does. > > - do you think it could help in scenario B) a virtual hierarchy? I guess I > could filter every request, look up the actual target and forward > (e.g. SSI) > the request. I was thinking I could do that just as well with a servlet of > my own. My problem with this is that I'm essentially wrapping the Slide > webapp then. Ah, maybe that's why you're suggesting filters: I can just > config one in the request chain. > > - gee. Now that I re-read C) below, it says 'filter'. :-o Doh! > > Ok, I'll bite. Filter's might be the way to go. My only > discomfort with them > is that I'm not quite sure how to determine from the request what Slide > object is being requested (I'm going to want some properties from it to > determine whether to 'filter'). > > Per > > > I am wondering if anyone's done any of the following using Slide, > > and if so, > > how: > > > > A) defined callbacks for the different WebDAV actions. E.g. every > > time a new > > file is created, locked, deleted, call a function which does ancillary > > processing. [Should I do this by subclassing the servlet or is there a > > detached callback/listener framework in Slide's underlying CMS] > > > > B) mapped a virtual hierarchy to a different, real storage > hierarchy. E.g. > > used Slide to manage assets in a URN hierarchy which uniquely identifies > > each asset but presents a different hierarchy to the user. An example: > > documents stored in Slide are in > > > > slide://hostname/folderID/collectionID/documentID > > > > but the user's view of the world is specific to his rights and > privileges: > > > > http://hostname/username/clients/clientABC > > > > Perhaps this could/should be done using servlet include/forwarding. > > > > > > C) A simpler version of B) perhaps: filter the list of > > directories, within a > > hierarchy before returning the full list to the user. E.g. > > > > /foo > > /foo/bar > > /foo/cow <- want to hide this one on Tuesdays > > > > > > Per > > > > > > -- > > 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]> > > -- 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]>
