forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Victor Mote" <...@outfitr.com>
Subject RE: directory/menu structure
Date Tue, 08 Apr 2003 16:13:49 GMT
Jeff Turner wrote:

> > Sorry to be so slow responding. After playing with it for a
> bit, the short
> > answer is "no". IMO, the web site is simply a "view" of the
> documentation,
> > and its structure should be independent of the physical
> arrangement of the
> > content files.
>
> Not particularly relevant to the tabs discussion but..

Well, I am misunderstanding something then. I guess I am thinking of tabs as
being a first-level menu. I am also assuming that site.xml is book.xml writ
large, i.e. for the whole site.

> The website is already completely independent of filesystem structure.
> We have a Cocoon sitemap.xmap file that does the mapping.  site.xml has
> no effect on the actual URI space - it just defines the menu.

I don't follow. The menu that is associated with a file (i.e. the one that
is pasted on the left side of the document) is built from the book.xml file
that is in that document's directory. The selected tab is determined from
the file's URI. In both cases, those are tied to a physical URI, not to
anything defined in book.xml or site.xml.

> > So, preferably, the site.xml would have something like this
> > (I posted something similar in a previous message, but am
> expanding on it a
> > bit here):
> >
> >   <site>
> >     <tab>
> >       <menu>
> >         <menu-item>
> >         <menu-item>
> >       </menu>
> >       <menu>
> >         ...
> >       </menu>
> >     </tab>
> >     <tab>
> >       ...
> >     </tab>
> >   </site>
>
> Yes, that could be done.  Hmm.. perhaps a tab attribute would work better
> than a custom element?

Well, tabs are two-way. 1) When you click a tab, you see menu items under
it. 2) When you click a menu item that opens a document, that document needs
to know which tab and related menus it should display. The first concept is
many-to-one, i.e. more than one tab & related menu could point to the same
document. By definition (unless using frames), the second concept is
one-to-one, i.e. a given document can only point to one tab & related
menu -- forrest hard-codes the tab & menu information right into the file.
The tab attribute is exactly what I proposed further down in the original
email, but that only works for identifying the second concept. You still
need something to define the relationship between tabs (high-level menus),
menus, optional submenus, and documents. Since it is a hierarchical
relationship, it seems natural to define it explicitly in the xml.

> <menu tab="Foo">
>    ...
> </menu>
> <menu tab="Bar">
>    ...
> </menu>
>
> Tabbiness is more a property of a node (and it's children) than a
> separate thing.  Can't have a tab without an associated page.

You are correct that a tab needs to have an associated page. That can easily
be an attribute of the tab element, or could default to the first
subordinate document item.

> > After thinking about this for a while, I see that the problem is that a
> > document could appear in more than one menu, which could be ambiguous in
> > terms of building a menu & tab bar for it.
>
> I think having a @tab attribute would solve this problem.  We could say
> that @tab works like namespaces: inherit from the parent, unless defined.

I agree, as long as you deal somehow with the many-to-one aspect.

> <menu tab="Foo">
>    ...
>    <!-- These menu items all have @tab="Foo" -->
> </menu>
> <menu tab="Bar">
>    ...
>    <!-- @tab="Bar" -->
>    <menu href="special/index.html" tab="Foo">
>      <!-- This entry has overridden @tab="Foo" -->
>    </menu>
> </menu>
>
> Would that work?

Only if, as I said, you allow a document to appear only once within this
structure, or otherwise deal with the ambiguity of having the same document
point to different tabs.

Victor Mote


Mime
View raw message