cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Koberg <>
Subject Re: [report] xml-site update
Date Sat, 01 Jun 2002 13:52:06 GMT
Robert Koberg wrote:

> Diana Shannon wrote:
>> On Saturday, June 1, 2002, at 08:16  AM, Robert Koberg wrote:
>>>>> I think we should attempt to catch internal links problems prior 
>>>>> to commits with the live site cvs.
>>>> Yes. The LinkAlarm run will check them too, but that does
>>>> not hurt.
>>> It seems so strange that you hard code these things...
>>> This should never be a problem. I don't understand the reluctance to 
>>> use basic XSLT features, but by referencing the link/menu data 
>>> through the document function (or whatever the right way is for 
>>> cocoon - strange that it has to be different...) you totally 
>>> eliminate this problem. If the link exists it is guaranteed to be 
>>> correct. If a link 'links' to something that does not exist, either 
>>> do not render the <a href/> (just the text) or wrap it in a span 
>>> that has font-color:red or something.
>> Part of the problem, Rob, is that we are dealing with static html 
>> files that are merged together. The live site is produced from static 
>> html files which result from release branch builds -- also html. We 
>> have to take partial results of a release branch build (files and 
>> directories) and merge with existing live site cvs files and 
>> directories. It's inefficient, yes, but Forrest will address this issue.
> Really, how? Last week I tried to figure it out given the constraints 
> of not using the XPath document function or include/import. I could 
> not figure out how to do it. I raised the issue about hard-coded links 
> on the forrest list and only one person took the time to investigate 
> it. I gave a concrete example. Then he (Ivelin) posed the question to 
> group asking if the thread was helpful. I think Steven responded 
> simply with 'yes.'
> So how will forrest address this? Perhaps a nodeset could be created 
> and cached to be passed into every transformation?? Or just simply use 
> XPath's document function.

Another way to handle it would be to use a cocoon URIResolver and then 
you can eliminate the caching problems (for xpath document and xsl 
import/include). Perhaps you folks feel this is mixing concerns, but I 
see it now that you are removing concerns from something that should be 


To unsubscribe, e-mail:
For additional commands, email:

View raw message