The fellow readers of my blog might have noticed that pretty much on top of my Cocoon rant list is how unnecessarily complex is to build relocatable Cocoon applications, that is applications who can work no matter how shallow or deep are nested within the Cocoon hierarchy. The problem I'm facing is that in order to build relocatable links you either have to:
1. resort to strictly relative links, something that quickly becomes unmanageable;
2. perform string manipulation by substracting request.getSitemapURI() from request.getRequestURI(). This is painful and slow in XSLT, as an example, and requires two parameters instead than the one you're actually looking for (hence being error prone at best);
The solution is technically a piece of cake, and we have been using a braindead custom inputmodule exactly for that. However, I feel that this data should be available from the Cocoon environment straight away, the best place being o.a.c.environment.Request (which will provide immediate user access through the RequestInputModule). I am very bad in naming stuff, but I would say that something like getSitemapPath() could do the trick. Being this a change in the core environment API, no matter how harmless, the issue might deserve some discussion and a vote. Or a big slap in my face if I'm missing the obvious solution. :-)
So, is that only me having to face this issue day in day out?
No, clearly not.
Again, damn it, this is fixed very elegantly in the real block design:
<link rel="stylesheet" src="block:skin:/styles/default.css"/>
then you just have to place a
<map:tranform type="linkmounter"/>
before your serializers and voila', it becomes
<link ref="stylesheet" src="/mypath/myapp/styles/default.css"/>
note how the linkmounter will need to know two things:
1) the URL of the public URL where the cocoon root is mount (might not be inferred from the servlet API because of proxying!)
2) how to ask the block manager where 'skin' is mount in the cocoon URL space
Simple, elegant and polymorphic safe.
-- Stefano.
