forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
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 
already).

>>Project data:
...
> 
> All sounds good.
> 
> Seems we're converging on the same data/properties division that Maven
> has:
 >
> project.xml           # Project Object Model
> project.properties    # 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    # Forrest properties

Hmmm...

> 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.

Correct.

>>Then we have the forrest.properties, 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 forrest.properties:
> 
> # Properties describing the user's project (used in Ant)
> project.name
> project.skin
> 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.

Agreed.

>>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 forrest.properties for Ant but for Cocoon, we 
>>could as well:
> 
> We need them for Ant as well.  Ant does the XML validation, and we
> need forrest.properties 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 
xmlproperty.

>>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  # Forrest properties:

Yes.

> 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 cocoon.properties)

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                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


Mime
View raw message