forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Re: Fixing menus
Date Wed, 09 Apr 2003 16:18:36 GMT
On Wed, Apr 09, 2003 at 10:45:26AM +0200, Nicola Ken Barozzi wrote:
> Jeff Turner wrote, On 09/04/2003 6.57:
> >On Tue, Apr 08, 2003 at 07:05:46PM +0200, Nicola Ken Barozzi wrote:
> >...
> >>Since xdoc11 is used by our users, I reckon that menu.xml /could/ be as 
> >>well used, by following the analogy. Putting it backwards... why not do:
> >>
> >>               site.xml
> >>User   -->  navigation.xml     --->  navigation.xml   --->  HTML
> >>               book.xml
> >>?
> >
> >Yes, could do that, but then we've got a single contract with users *and*
> >skinwriters.  Seems cleaner to have them separate, even if the
> >navigation.xml and menu.xml formats are identical to start with.  The
> >navigation2menu.xsl stylesheet would just do a no-op.
> Ok, agreed. Similar to what we have done with book.xml, but this time 
> it's declared as being different right from the start and can evolve as 
> we need without problems.


> +1
> >>Second question (which invalidates the first ;-P)... how does it 
> >>integrate with the rest of the descriptors?
> >>
> >>I feel a bit confused by having site, book, navigation... how would a 
> >>user use them?
> >
> >Currently, book.xml is our 'source' format and our 'intermediate' format.
> >site.xml is an alternative source format.  If we have a menu.xml
> >intermediate format, then everything else (site.xml, navigation.xml,
> >book.xml) is a source format.
> I understand that book.xml will be kept for dir-specific navs, but 
> what's the difference between navigation.xml and site.xml? How would 
> users use the two? Can't we scrape site.xml in favor of navigation.xml? 
> Are they mutually exclusive?

site.xml and navigation.xml wouldn't be mutually exclusive, in exactly
the same way book.xml and site.xml aren't mutually exclusive - they're
useful for different things.  Changing book.xml to navigation.xml doesn't
change that balance.

site.xml offers a few advantages over navigation.xml:

 - Cumulative paths, i.e.:

   <foo href="foo/">
     <bar href="bar.html">
       <baz href="#baz"/>   <!-- The href here is foo/bar.html#baz -->

 - All the things linkrewriter needs.  Built-in ids in the form of
   element names, and the <external-refs> section for ext: links.  We can
   add a 'id' attribute to navigation.xml, solving the first issue, but
   not the second.

 - We can dork around with it without breaking compatibility with Maven.

OTOH, navigation.xml can precisely define a special menu for a directory,
something site.xml can't do.

> Also, why not make book.xml in each dir an *additional* source of links, 

Additional to what?

> by adding them to the navigation instead of replacing? With CSS then 
> skinwriters can decide to exclude what they prefer.
> >>My best initial guess:
> >>
> >>              (skinconf.xml)
> >>User   -->     site.xml       --->  navigation.xml   --->  HTML
> >>               book.xml
> >>
> >>Skinconf.xml is also keeping metadata about the site, that could as well 
> >>be in site.xml. Not that I'm very keen on moving it there, given all the 
> >>code that has to be changed, but just taking note of it to see what you 
> >>think.
> >
> >I thought skinconf was logically an extension of the Gump project
> >descriptor?  
> Hmmm... does it describe the project? IMHO no

? Certainly seems to "describe the project" to me.. project-name/url,
group-name/url, copyright, credits.  Half that info probably ought to be
in a regular Gump descriptor (its in Maven's project.xml).

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


> >The other formats (site.xml, book.xml, navigation.xml) are
> >strictly for menus, separate from project data.  Just like in Maven,
> >navigation.xml is separate from the POM.
> Yes, if the above stands, the concept is correct.
> -- 
> Nicola Ken Barozzi         
>             - verba volant, scripta manent -
>    (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------

View raw message