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: Fixing menus
Date Wed, 09 Apr 2003 16:26:47 GMT


Jeff Turner wrote, On 09/04/2003 18.18:
> On Wed, Apr 09, 2003 at 10:45:26AM +0200, Nicola Ken Barozzi wrote:
> 
>>Jeff Turner wrote, On 09/04/2003 6.57:
...
>>>>I feel a bit confused by having site, book, navigation... how would a 
>>>>user use them?
...
>>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.

So it seems that site.xml is a superset of navigation.xml, and that with 
a few additions it can be even better.

Honestly, I don't see why as a user I would use navigation.xml given 
that site.xml is there... I thought that we could somewhat enhance 
navigation.xml so that the Maven one is a subset of it, thus compatible.

Dunno though.

Who would want to use navigation.xml given that id does not give us link 
rewriting? One should then make a site.xml *and* a navigation.xml... not 
nice. So if I want to use rewriting, why would I want navigation? and if 
I have navigation, why can't I have link rewriting?

Crappy phrases, hope you get my doubts.

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

On the navigation, I have site.xml contents. Below or above it I could 
*also* have book.xml contents, for page-specific navigation.

The site.xml xontents would still be there, but maybe collapsed for 
screen space.

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

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?

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

Yes.

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.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


Mime
View raw message