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. >> >>How? >> >>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. -- Stefano.
