forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Re: [PROPOSAL] Forrest site configuration
Date Thu, 09 Oct 2003 10:12:17 GMT
On Tue, Oct 07, 2003 at 02:34:05PM +0200, Nicola Ken Barozzi wrote:
> Currently, configuration and extension of Forrest is done with these
> files relative to the current directory:
>   a - *.xmaps
>   b -
>   c - skinconf.xml
> Point (a) IMHO has only one way of making it better: not *having* to
> extend xmaps to be able to do the most used extension features.
> The most common extensions I see that are done in xmaps are:
>   - addition of DTDs


>   - insertion of extra sources

Or rather, special handling of some sources (usually those with custom
DTDs), like FOP's compliance.xml

> Point (b) is about validation, source dirs, and other dirs places. In
> common with (a) there is the source dirs stuff: define the default ones,
> another to add to them.
> Finally (c) is about the configuration of the skin, so that it is
> customized. This has proven to be succesful, so I regard it as a
> reference about how to do the rest.
> Note that I want to make it possible for a single Forrest webapp to
> serve different sites, and so to make it also possible for projects that
> have subprojects to share the same skinconf and infos.

Sounds like an interesting case..

>   Proposal
> ----------
> custom *.xmaps     ->

All custom *.xmap files, even if they have nothing to do with DTDs?

> -> srcconf.xml
>                     -> gump.xml (optional)
> skinconf.xml       == skinconf.xml
> In essence, each project would have two descriptors:
>    srcconf.xml  (content)
>    skinconf.xml (style)
> Forrest would find them in a predefined location in the directory, and
> srcconf is not compulsory, so the default Forrest would be exactly like
> now. :-)
> If a user wants to change the location of the sources or add to them, he
> would have to add a srcconf.xml file next to skinconf.xml.

So I gather the 'predefined location' for srcconf.xml is
src/documentation?  That hardcodes the one directory most likely to
change ;)  Alternatively if this file lives in the project root, it
becomes far too generically named ('srcconf') and confusable with Ant

> If he wants to change the location where Forrest looks for these
> descriptors, he would have to add the information to its project
> descriptor, that can be the Gump one *or* the Maven one.

All that to avoid hardcoding src/documentation/.  Yuck..

> The skinconf logic should be intelligent enough to look for the usual
> project descriptor names and locations and extract these two pieces of
> information regardless the descriptor (using // xpaths for example).
> As for DTDpacks, they would be extensions exactly like the skins. Hence
> I will change skins.xml to extensions.xml and also add the possibility
> of adding extra DTDs there. We will thus have a single way of adding
> extensions; the only extra thing to do is to add the downloaded DTDs to
> the resolver file in the installed Forrest, but that's easy enough.

>From what I've seen, most people tweak existing DTDs to come up with new
ones.  They're not importing completely new, prepackaged DTD sets.  The
only place I can see a 'DTDpack' being useful is with Docbook.  Any other

> I think that this is the best solution to date to the
> descriptor-sources-extensions stuff that Forrest needs. It makes it
> also possible for example to make a webapp out of many sites, by simply
> feeding forrest a descriptor with all the sites it has to render, and
> at which relative URI.

I may be being dense, but I don't see the relation between what you've
described above, and the ability to generate composite sites.

> Finally, here is the proposal of an initial srcconf.xml:
> <srcconf xmlns=""
>           xmlns:map="">
>    <map:components>
>      <map:matchers default="wildcard">
>        <map:matcher name="wildcard" src="o.a.c.m.WildcardURIMatcher"/>
>        <map:matcher name="regexp" src="o.a.c.m.RegexpURIMatcher"/>
>      </map:matchers>
>      <map:selectors>
>       <map:selector name="exists" src="o.a.c.s.ResourceExistsSelector" />
>      </map:selectors>
>    </map:components>
>    <matches>
>      <map:match type="wildcard" pattern="**.gif">
>         <location src="content/xdocs/{1}.gif">
>      </map:match>
>      <map:match type="wildcard" pattern="**.xml">
>        <map:select type="exists">
>          <map:when test="content/xdocs/{1}.ihtml">
>             <location src="content/xdocs/{1}.ihtml">
>          </map:when>
>          <map:when test="content/xdocs/{1}.txt">
>            <location src="content/xdocs/{1}{2}.txt">
>          </map:when>
>          <map:otherwise>
>            <!-- there is a default srcconf that handles other sources -->
>            <location src="{default}">
>          </map:otherwise>
>       </map:select>
>     </map:match>
>    </matches>
> </srcconf>
> Does it look like sitemap.xmap?

Why yes it does.  Why not use xmaps instead?  Parametrized ones, that is..

    <map:generate src="{project:content.xdocs}{1}.xml" />
    <map:call resource="transform-to-document">
      <map:parameter name="src" value="{project:content.xdocs}{1}.xml" />
    <map:serialize type="xml-document"/>

That allows the exact location of 'content.xdocs' to be customized in an XML or
.properties file.

> Before anyone starts asking why not use xmaps instead, which I have done
> with myself a lot too, here are the answers:
> 1 - external xmaps constrain our ability to refactor the sitemaps,
>      also for speed, as the cocoon:// protocol is not a speed daemon
> 2 - if does not enable us to deploy multiple forrest sites in a single
>      Forrest instance

I don't see how this would work anyway.

> 3 - with DTD extensions we don't need transformations in this file, and
>      this will also add the benefit of separating source and view
> The upside of the above is also that it looks like sitemap.xmap, which
> could help users dwelve into cocoon if they ever really need extra
> functionality. Also it uses the Cocoon matchers, which is a nice reuse
> of powerful finctionality.

So how would it work?


> Blocks? When they will come, we will se iff-how to change this. It will
> take some time before they are done, even more before they become solid
> and 2.2 is our of the door.
> Thoughts?
> -- 
> Nicola Ken Barozzi         
>             - verba volant, scripta manent -
>    (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------

View raw message