Return-Path: 
 <cocoon-dev-return-27536-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 39434 invoked by uid 500); 1 Jun 2002 21:08:16 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 39423 invoked from network); 1 Jun 2002 21:08:16 -0000
Date: Sat, 1 Jun 2002 17:10:32 -0400
Subject: Re: [report] xml-site update
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v472)
From: Diana Shannon <shannon@apache.org>
To: cocoon-dev@xml.apache.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <3CF8CC41.2090008@koberg.com>
Message-Id: <026D5EA6-75A4-11D6-9902-0030653FE818@apache.org>
X-Mailer: Apple Mail (2.472)
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N


On Saturday, June 1, 2002, at 09:29  AM, Robert Koberg wrote:
>>> 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.'

Give our dear friend Steven a break. Don't you think he had at least one 
slightly more important issue to deal with last week? I'm completely 
amazed he even has time to read emails, let alone respond.
     http://marc.theaimsgroup.com/?l=forrest-dev&m=102235588403970&w=2

Diana


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org