cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] FOM
Date Tue, 27 May 2003 22:52:39 GMT
on 5/27/03 2:25 PM Giacomo Pati wrote:

> On Tue, 27 May 2003, Stefano Mazzocchi wrote:
> <snip/>
>>This is, IMO, what the FOM requires. Nothing less, nothing more. But let
>>me explain why I consider flow-driven URI handling harmful.
>>Today, once you mount your web application, you don't know where it
>>resides. In order to keep your webapp relocatable on your URI space,
>>either you keep everything relative (including the many horrible
>>../../../ which is easy to get wrong) or you re-invert the control by
>>finding out yourself where you have been mounted and tweak URI accordingly.
>>I strongly dislike both approaches because they are error prone.
>>IMO, it should be cocoon to transparently adapt the URI right before
>>serializing the output to the client.
>>Using a link-translating protocol.
> Hmm.. the only occasion where we had the need for the URI handling was for
> generating PDF reports with FOP which includes some graphics (ie. logos). I know
> this isn't a Cocoons fault but as long as FOP needs absolute path for embeded
> graphics there is the need for URI handling. I don't know if you had in mind to
> have the link-translating protocol handle absolute paths to the file system.

No. the link-translating protocol should translate URIs (at block level)
to URLs (at site level) for browser consumption.

But if URI to file-system-location is needed, I would rather extend the
link-translating behavior rather than giving direct access to stuff like
getRealPath() which smells of hacky a thousands miles away.


View raw message