cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: DispatcherServlet
Date Thu, 31 May 2007 13:51:58 GMT
What am I missing? All of these syntaxes look invalid to me.  Why isn't 
the syntax of the normal form


 From the discussions it isn't obvious to me if the block name should be 
the server name or part of the path.


Alexander Klimetschek wrote:
> Hi guys,
> I have a hack for our local Cocoon release that integrates global bean 
> ids into the servlet protocol. It's not perfect and that's why I 
> didn't provide a patch yet for 
> (and because I have 
> so much to do for our upcoming release).
> But I have some practical experience with that, so I can help in the 
> discussion:
> Reinhard Poetz schrieb:
> > servlet:byId:com.mycompany.block1.servlet:/...
> > servlet:!com.mycompany.block1.servlet:/...
> > servlet:~com.mycompany.block1.servlet:/...
> > servlet:@com.mycompany.block1.servlet:/...
> >
> > My favorite is the last one.
> 1) the @ will make the URL invalid (it's reservered for 
> in the URL pattern)
> 2) I simply put the global bean id instead of the shorthand - in 
> ServletServiceContext:getNamedContext() I simply look for the 
> shorthand first and if that fails I do a lookup in the beanfactory 
> assuming it is the global bean id, eg.:
> 3) IMPORTANT: one very important thing to note is that the servlet 
> protocol is caller-dependent: servlet:SUPER: has a special meaning, 
> ie. two calls to servlet:SUPER: from to different blocks are not 
> identical - thus you have to add a marker for those calls. My pattern 
> is to add "__super" after the global bean id, eg.:
> 4) I simply make the URLs absolute in the ServletSource() constructor 
> and set the systemId of the source to the absolute path. Because any 
> include/import mechanism (like in XSLT) will use source.getURI() to 
> resolve the relative filename, it is important that this is fully 
> resolvable by the servlet source implementation - 2) and 3) (but here 
> I don't tell any new stuff ;-)
> 5) Different story, but also regarding globally unique keys: 
> Environment.getURIPrefix() must be set to have the filename-part of 
> the cache keys globally unique (it is empty in the current 
> implementation, don't know when it was introduced and for what; but it 
> is very useful, since it will be used for cache keys) - I simply use 
> the mount path for the uri prefix, this makes the cache keys readable, 
> because they look like the real URLs the browser sees.
> Alex

View raw message