forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <je...@apache.org>
Subject Re: Skin rewrite: 0.2 release?
Date Mon, 11 Nov 2002 17:43:09 GMT
On Mon, Nov 11, 2002 at 05:53:16PM +0100, Nicola Ken Barozzi wrote:
...
> >>I'm finishing just now to patch the sitemap to be able to accept sources 
> >>from src/documentation/content directly instead of in the xdocs dir.
> >
> >
> >Do you mean, allow XML directly in the content/ directory?  Is that a
> >good idea? :) It's going to screw up validation..
> 
> Ok, then I just did it :-(
> Will fix later, I have to run now.
> 
> >Users can always set project.xdocs-dir=${project.content-dir} to have
> >that..
> >
> >What's the use-case that isn't met currently?  
> 
> Ahem... so that we will be ready when we won't copy the sources
> anymore?  I'd like to see all the dir info in the sitemap, movung
> things around during the build is a hack IMHO.

Yes, but adding sitemap rules to load XML from anywhere doesn't get us
closer to solving that problem.

Currently, we have a convention that content/xdocs contains XML docs.
That convention holds regardless of whether 'content/xdocs' was copied or
not.  The sitemap doesn't care: it just wants 'content/xdocs' to contain
XML.  Breaking the convention achieves nothing.

Put another way: imagine we don't need to copy, and our sitemap is
'rooted' in src/documentation.  What default sitemap rules should we
provide?

a) The sitemap tries to be as general as possible:

content/**/*.xml -> **/*.html
content/**/*.xml -> **/*.pdf
content/**/*.png -> **/*.png
content/**/*.gif -> **/*.gif
...

b) The sitemap only contains rules for the pre-established directories:

content/xdocs/**/*.xml  -> *.html
content/xdocs/**/*.xml  -> *.pdf
content/images/*.png -> *.png
content/images/*.gif -> *.gif
...


I think that b) is better, because separating 'kinds of content' is good
practice, and we shouldn't be encouraging a free-for-all.

Also, b) can easily be made to emulate a), because we can parametrise
what we regard as "the xdocs directory". Eg we'd have a file describing
the content layout:

<forrest-layout>
  <xdocs dir="src/xdocs"/>
  <skins dir="src/skins"/>
  ...
</forrest-layout>

and then the sitemap would use an input module (XMLModule) to read this:

{content:xdocs-dir}/**/*.xml  -> *.html

Then if the user wanted to, they could abadon the xdocs/ convention and
map {content:xdocs-dir} to ${content:content-dir}.

> What do others think? Probably I'm just getting old and my brain fried...
> 
> >>It also searches in the legacy xdocs dir for compatibility.
> >>
> >>I want this to go in our first "unofficial" release, so we don't make 
> >>users change doc source locations later on.
> >
> >Currently, everything is located through a fine-grained set of project.*
> >properties.  It is easy to make things coarser-grained.
> 
> I wanna zap them and make all the content in a single dir, as I thought 
> we had decided on.
> 
> Single dir space -> single URI space

It already is.  Everything in content/ can currently be accessed from the
sitemap.  The choice is, what default rules to we want to provide to map
that content to public URIs.  We can try to be as general as possible in
the mapping, or we can stick to some conventions, while allowing the
possibility of breaking those conventions.  I'd prefer the latter..


--Jeff

> -- 
> Nicola Ken Barozzi                   nicolaken@apache.org
>             - verba volant, scripta manent -
>    (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
> 

Mime
View raw message