Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Message-ID: <40DFD5B7.3000505@gmx.at>
Date: Mon, 28 Jun 2004 10:24:23 +0200
From: Lorenz Froihofer <Lorenz.F@gmx.at>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616
MIME-Version: 1.0
To: dev@forrest.apache.org
Subject: Re: Project sitemap mount and copyless
References: <cb6us3$suv$1@sea.gmane.org>
 <1087976828.9371.2852.camel@ighp>	 <cbgqam$cvq$1@sea.gmane.org>
 <1088236726.18565.1190.camel@ighp> <cbngei$rnj$1@sea.gmane.org>
In-Reply-To: <cbngei$rnj$1@sea.gmane.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Nicola Ken Barozzi wrote:
> David Crossley wrote:
> 
>> Nicola Ken Barozzi wrote:
> 
> ...
> 
>>> My impression is that we should only need to give users the 
>>> possibility of using a sitemap to generate extra source documents 
>>> using Cocoon, and nothing more.
>>
>>
>> The cases where i have needed to use project sitemaps:
>>
>> * Some source docs which use full DocBook and render them
>> with the complete DocBook XSL, e.g. Apache Xml Commons.
>> http://xml.apache.org/commons/components/resolver/
>> See the "Article".
>>
>> * Where we have other complex tables that we need to be
>> integrated into a Forrest-built site.
>> http://www.indexgeo.net/zalarm/
>>
>> * The scenario described in the "Using Forrest" doc.
>> http://forrest.apache.org/docs/your-project.html#sitemap.xmap
>>
>> All of these have been achieved by adding our own project
>> sitemap and our own stylesheets.
>>
>> I gather that is the sort of thing we intend to continue to
>> facilitate.
> 
> 
> Agreed.
> 
>>> Any other customization would be something that touches Forrest 
>>> itself and should be done by actually changing Forrest.
>>
>>
>> What other thing can you imagine that people might need?

I use a custom sitemap because I do not want to rewrite all the existing 
HTML documents as Forrest documents. By using a custom file extension 
(e.g. .xhtml) it is further possible to perform some transformations on 
them (e.g. table coloring).

Furthermore, this allows the flexibility of using full HTML in case you 
need it, e.g. some documents that have a unique layout and where it is 
not worth to create a new document type for them.

> 
> 
> Personally nothing.
> 
> Currently users can do anything with these sitemaps, as they touch the 
> inner workings of Forrest.
> 
> I want to make the extensions more defined so that we can move Forrest 
> forward without the fear of breaking people's customizations.
> 
> What about this proposal:
> 
> - we mount a sitemap that resolves uris in a defined space, for
>   example /forrest-user-sitemap
> - this pipeline has to give us the docs in xdoc format

I guess this would mean to write a custom stylesheet to transform the 
existing HTML documents with custom transformations into a Forrest 
document.

Furthermore, by using this approach any kind of document would be 
limited to the xdoc format (I guess, the Forrest document format is 
meant here). What happens if a user needs more flexibility in  formatting?

> - we have Forrest check if the document resolves in this space
>   before using other sources
> 
> Let me explain.
> 
> Let's say that we want Forrest to render a table from some database data 
> at the URL /mydata.html
> 
> What I have to do is make my sitemap give an xdoc representation of this 
> table under /forrest-user-sitemap/mydata.xml
> 
> In this way Forrest will search there first before looking on the disk, 
> and render it correctly under /mydata.html
> 

Kind regards,
   Lorenz Froihofer.