Mailing-List: contact forrest-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: forrest-dev@xml.apache.org
Message-ID: <B6352CB87AA70442A1C6F49E6B658C9801EEFF@POSTMAN.flagship.ru>
From: Piroumian Konstantin <KPiroumian@protek.com>
To: "'forrest-dev@xml.apache.org'" <forrest-dev@xml.apache.org>
Subject: RE: sitemap modularity
Date: Tue, 23 Jul 2002 19:25:46 +0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="koi8-r"
Status: O

> From: Steven Noels [mailto:stevenn@outerthought.org] 
> 
> Dear all,
> 
> seems some of us are starting to have actual use cases for 
> Forrest - good!
> 
> This is just to re-start the discussion we had earlier on sitemap 
> modularity, i.e. having a root sitemap for content types we 'own' and 
> manage, and some automounting sitemap setup for people 
> wanting to customize.

We can also 'own' some predefined sub-sitemaps, e.g. FAQs, etc.

> 
> If we want to go forward with this, I assume we will want to 
> give them 
> an example of this, perhaps using some common, but not too 
> sophisticated 
> content type such as FAQs.

Why not provide already defined types for the _all_ common cases with a
possibility to customize them by changing the xslt, css and finally the
sitemap for that area?

> 
> There's a number of issues, though...
> 
> 1) @skinname@ filtering/rewriting inside the Ant copy tasks prior to 
> generation...
>     - using Ant for customizing rendition behaviour seems 
> like a big hack
>       to me, and we should find some way around it, perhaps 
> using sitemap
>       parameters, maybe being set by those new input modules 
> of Cocoon...
>       opinions please

+1 for InputModules. Sitemap parameters cannot be set externally (maybe
yet), so they should be coded at least in the root sitemap. InputModules can
provide even dynamic parameters based on user preferences (in future).

>     - parametrization of XSLT stylesheets using the same 
> mechanism seems
>       like an equally big hack, too, and we should migrate 
> this to proper
>       sitemap aggregation, a process which depends on some 
> configuration
>       file inserting those as XSLT parameters, or something else

Don't quite understand what do you mean, but seems that the same solution
can be used here (input modules).

>     - for choosing the skin to be used upon generation/for 
> the webapp, we
>       could also move the selected skin into a fixed location 
> instead of
>       moving them all and having to do this @skinname@ stuff

+1

> 
> 2) we should decide what to do with the 'community' section 
> of Dia~a and 
> David... should this stuff be moved into its own sitemap, or be made 
> part of the core setup?

I think that it should moved into several sub-sitemaps, e.g.: FAQ, HowTo,
etc. - one for every independent functional area.

Konstantin

P.S. Sorry for not participating in the development - too busy until 15th of
August.

> 
> </Steven>
> -- 
> Steven Noels                            http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> stevenn@outerthought.org                      stevenn@apache.org
>