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 13:22:16 GMT

Jeff Turner wrote, On 10/04/2003 12.56:
> On Wed, Apr 09, 2003 at 06:26:47PM +0200, Nicola Ken Barozzi wrote:
>>Jeff Turner wrote, On 09/04/2003 18.18:
> ...
>>>OTOH, navigation.xml can precisely define a special menu for a directory,
>>>something site.xml can't do.
>>So it seems that site.xml is a superset of navigation.xml, and that with 
>>a few additions it can be even better.
> If we could allow a site.xml per directory which augments a central
> site.xml, then it would be a superset of what book.xml/navigation.xml
> offers.


But again, I miss the role of having the three.
If we have site.xml as you suggest, we could as well do without either. 
So as a user I would never use them, only the enhanced site.xml.

I still don't get what an explicit use of navigation.xml brings us in 
this case.

I would like as an alternative to allow *only* navigation.xml, because 
it brings us closer, but having also site.xml seems confusing. Hence 
maybe it's better not to support it explicitly.


> ...
>>Hmmm, ok, conceded. I put it in Gump's descriptor for my projects, but 
>>somewhere we decided not to go that way IIRC. What would you say about 
>>it now?
> I think we should perhaps define a specification of what data we need for
> a Forrest site, and then figure out how to represent it as a:
>  - Gump descriptor
>  - Maven descriptor
>  - Custom XML for people who don't care about Gump/Maven
> This abstract data model should include the directory layout of the site,
> currently captured in
> We could have a sitemap pipeline to convert external formats into a
> common internal format.
> Haven't really thought this out though.

The concept seems nice,

>>>>and that's why I talk about putting in site.xml, that is where users
>>>>would maybe look how to config the site... just ramblings, leave it, I
>>>>have no real intention of changing it, and overmore I don't have clear
>>>>alternatives myself.
>>>That's where I'm at too: not sure how to fix it, leaving it until things
>>>become clearer.
>>Personally I like having that info in Gump descriptors. I am writing a 
>>stylesheet that takes gump's merged descriptors and makes a site out of 
>>it, *also* with the infos like the ones above.
>>Given that Maven can create a Gumpo descriptor from his already, I tend 
>>to think that we could use the Gump descriptor for it.
>>Not that sure though, I might not be seeing nasty implications.
> Sounds alright to me.

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

Project data:


   <!-- mandatory project logo
        skin: forrest-site renders it at the top -->

   <!-- optional group logo
        skin: forrest-site renders it at the top-left corner -->

   <!-- optional host logo (e.g. sourceforge logo)
        skin: forrest-site renders it at the bottom-left corner -->

   <!-- The following are used to construct a copyright statement -->
   <vendor>The Krysalis Community Project</vendor>

       <name>Built with Apache Forrest</name>

IMHO these should go in the gump descriptor. I agree though that they 
should be extracted to a common format, merged with all datas, and fed 
that way into Forrest.

Anyway, here are the infos about the presentational aspects of the site:

   <!-- Do we want to disable the Google search box? -->
   <!-- Do we want to disable the print link? -->
   <!-- Do we want to disable the PDF link? -->
   <!-- Do we want to disable the xml source link? -->
   <!-- Do we want to disable w3c compliance links? -->

   <!-- Some skins use this to form a 'breadcrumb trail' of links. If 
you don't
   want these, set the attributes to blank. The DTD purposefully 
requires them.
     <link1 name="krysalis at" 
     <link2 name="krysalis" href=""/>
     <link3 name="" href=""/>

These are not properly project properties, but may as well be put there, 
or with the new forrestproperties.

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.

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.

Since should not need for Ant but for Cocoon, we 
could as well:

1) read the Gump descriptor or equivalent and get the Forrest base
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)

Are we getting nearer to a solution?

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

View raw message