forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: Data models (Re: Fixing menus)
Date Thu, 10 Apr 2003 16:12:11 GMT

Jeff Turner wrote, On 10/04/2003 17.50:
> On Thu, Apr 10, 2003 at 03:22:16PM +0200, Nicola Ken Barozzi wrote:
>>Jeff Turner wrote, On 10/04/2003 12.56:
> There are some examples in Forrest's docs where site.xml-generated menus
> aren't appropriate:
> community/howto/bugzilla-patch/book.xml
> community/howto/cvs-ssh/book.xml
> I think allowing a site.xml in subdirectories that overrides the parent
> site.xml would solve these corner cases.
> In any case, we need to support book.xml for backwards-compatibility, and
> it can plug these holes in site.xml until we fix it.

Sounds good.

> ...
>>Ok then, let's see what goes into that descriptor.
>>>From skinconf.xml there are two kinds of tags IMHO: one tells us 
>>descriptove information about the *project* another about the *site*.
> Agreed, although the line is a bit fuzzy; the ability to specify
> height/width for credit images, for instance.  We can sort this out
> later..

I'd remove that and make Cocoon take that from the image (IIRC it can 

>>Project data:
> All sounds good.
> Seems we're converging on the same data/properties division that Maven
> has:
> project.xml           # Project Object Model
>    # Maven properties

And Centipede too BTW:

  module.xml            # Gump Object Model
  properties.xml        # Centipede properties

> Forrest:
> forrest.xml/gump.xml  # Documentation Object Model
>    # Forrest properties


> Where Maven uses a Betwixt to build a POM Java class, we can use a Cocoon
> pipeline + XMLModule to provide access to data in the sitemap and XSLTs.


>>Then we have the, that are intimately tied to 
>>Forrest. They are not part of the project descriptor, as they cannot 
>>really be used by anything else, only Forrest.
> There are currently two types of properties in
> # Properties describing the user's project (used in Ant)
> project.status
> project.content-dir
> project.conf-dir
> ...
> # Properties specifying Forrest's behaviour in the current project
> forrest.echo
> forrest.catalog.verbosity
> forrest.validate
> forrest.validate.xdocs
> forrest.validate.skinconf
> ...
> The project.* ones should be moved into {gump,forrest}.xml.


>>These should remain, only that I would like them under the documentation 
>>dir. We would only need an extra tag in the descriptor that tells us 
>>where the base dir for Forrest is.
> +1, makes sense.
>>Since should not need for Ant but for Cocoon, we 
>>could as well:
> We need them for Ant as well.  Ant does the XML validation, and we
> need to specify which files to validate.  There's
> also things like specifying the Cocoon debug level.

Ok then, I'd make it xml nevertheless, Ant can deal with that too with 

>>1) read the Gump descriptor or equivalent and get the Forrest base
>>   dir
>>2) run Cocoon with that info
>>3) Cocoon uses its pipelines to gather info from the Gump profile
>>   (converting on the fly to skinconf for compatibility), and
>>   source locations from forrest.xml (the properties)
> Oh, bit of terminology difference there.. seems you're thinking:
> gump.xml     # Project data
> forrest.xml  # Forrest properties
> I was thinking:
> forrest.xml         # Project data
>  # Forrest properties:


> Two issues here:
> - do we need a separate descriptor (my forrest.xml), or can all of
>   Forrest's data (including directory layout) be squeezed into
>   gump.xml?  I don't mind.

IMHO it can/should be squeezed into the Gump one. Stefano suggested that 
extra things in Gump descriptor are namespaced.

> - If our 'properties' data model is nice simple key:value pairs, then
>   I think we should use a flat .properties file instead of XML.
>   Reasons being:
>     - simpler to edit (see

I saw that Stefano reverted to properties.

>     - easier to describe in our documentation

NOt if we keep the xml similarly flat. Look at Cocoon's cli.xconf, it 
seems ok to me.

>     - easily mapped to Maven's properties


Honestly, I don't mind using properties, they only have two issues, that 
are not critical and that can be solved:

1) you don't see if a preperty ends in a space, while in xml it's evident
2) you cannot read them easily from Cocoon

Since I would like that Cocoon starts handling the "source" locations 
itself, it's easier to have it in xml.
But we can quite easily make a properties-module, no big deal either way.

>>Are we getting nearer to a solution?
> Yep :) Much closer.

That's cool :-)

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message