Jeff Turner wrote:
> On Mon, Mar 24, 2003 at 03:36:30PM -0700, Victor Mote wrote:
> > I made some decent progress today on getting my head into the
> trunk code,
> > and to document some of what I have learned. I am still confused by the
> > "Development" and "Redesign" tabs. At first, I thought that maybe
> > "Development" was for those who might be developing on the maintenance
> > branch, and "Redesign" for those on the trunk, but the title to
> the index
> > document under "Development" seems to belie that. I see that we
> have some
> > problems with the left nav bar that result from our directory
> structure. For
> > example, first click
> http://xml.apache.org/fop/design/index.html, then click
> > on the tab entitled "Understanding", and watch the left nav bar change,
> > which you would think it should not. Perhaps we made the two
> tabs to ease
> > that problem?
>
> Is 'understanding' a subsection of 'design', as the directory structure
> suggests?
Yes, but they are probably logically part of the same tab/left nav bar on
the web site.
> The menu changes because there are two different book.xml files (which
> generate the menus):
>
> src/documentation/content/xdocs/design/book.xml
> src/documentation/content/xdocs/design/understanding/book.xml
I understood that, and I assume that the book.xml that is in the same
directory as document.xml is the menu that attaches to document.html when it
is generated. The question then is, can that be overridden?
> As for tabs, they are completely reactive things. The tab with
> the longest
> matching @dir is "on". So FOP's tabs.xml has:
>
> <tab label="Home" dir=""/>
> <tab label="Development" dir="dev/"/>
> <tab label="Redesign" dir="design/"/>
> <tab label="alt design" dir="design/alt.design/"/>
>
> When viewing design/* or design/understanding/*, the longest
> matching tab is
> "Redesign".
Interesting & unexpected. Now I see why I got the counter-intuitive effect
that I saw. I don't know how well it fits with the Cocoon processing model
(I have a book on order that I hope will connect a few dots about Cocoon for
me), but a more clear parent-child hierarchical relationship in the site
setup would seem to be more flexible. In my mind, the left nav bar is a
subset of the tab that it is under. I might be able to be talked out of
that. I guess I would like to see:
<site>
<tab desc="Tab 1">
<menu desc="Tab 1, Menu 1">
<doc desc="Doc 1" path="abc.html"/>
<doc desc="Doc 2" path="xyz/abc.html"/>
</menu>
<menu desc="Tab 1, Menu 2">
<doc desc="Doc 3" path="xyz/pdq/abc.html"/>
</menu>
</tab>
<tab>Tab 2</tab>
....
</site>
Each document would get tab & nav information from the structure that it is
in. The above separates the directory structure from the web site hierarchy.
Although this seems good to me, it may rob Cocoon or Forrest of some of
their power (I'm not sure yet), and there may be other good reasons not to
do it. Anyway, thanks for the info. That does save me a bunch of work.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
