forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject [RT] Generalizing tabs (Re: [USER POLL/VOTE] Defining tabs?)
Date Fri, 16 May 2003 15:13:41 GMT
On Fri, May 16, 2003 at 03:28:36PM +0200, Nicola Ken Barozzi wrote:
> We have seen that there are different interpretations about what tabs 
> are, so we need to just decide what forrest thinks they are.
> Tabs can be seen as:
>  1 - shortcuts to certain parts of the site, as tabs in a book
>  2 - containers of separate parts of a site, as tabs on file folders.

In RT mode for a second, how about adding another option:

  3 - A tab is a visual flag indicating some property of the current page

Typically, we think of menus containing pages.  How about if, instead, we
consider the page's top-level menu as a _property_ of that page?  So all
manual/*.xml files have a 'classification' property with value "User Manual".

Why bother with this weird inverted thinking?  Because we can represent
_other_ properties as tabs too:

  - Page Format:

  __________________/ HTML | PDF | XML \___
 |  Some Documentation
 |  ------------------

  - Page language:

  __________________/ en | de | fr \_________
 |  Some English Documentation
 |  --------------------------

  - Applicable Software version:

  ________________/  C2.0 | C2.1 | C2.2-dev \____
 |  Doing XYZ in Cocoon 2.1
 |  -----------------------

  - Page status:

  ________________/ draft | published | obsolete \____
 |  Some Draft Documentation
 |  ------------------------

  - Page Review status:

  ______/ Unreviewed | Peer reviewed | Committer reviewed \____
 |  Some Wiki Documentation
 |  ------------------------

And our primary use-case:

 - Page classification (menu):
  __/ Home |  Manual | Samples \____
 |  Some Draft Documentation
 |  ------------------------

Visually, most of these tabs would be tiny things off to the right of the
tab bar.  We would want to fit more than one 'tabset' in the tab bar.
We'd want the category and format tabsets on by default.


Currently, tabs2menu.xsl takes the current page path, and uses this as a
'key' to lookup the current tab in tabs.xml.

We can generalize this quite simply: instead of doing the lookup in
tabs.xml (containing just 'classification' metadata), do the lookup on a
dynamically generated site.xml, which contains metadata for every file:

  <index label="Index" href="index.html"

Much of those site.xml attribute can be generated on the fly from page
<meta> tags.  The real thing would probably be RDF.

We would need a schema (RDFS? RNG?) declaring the possible attribute
values for our page metadata.  We'd need that to know, for example, that
'draft' is part of the set {draft, published, obsolete}.

So we've got an XML source of page metadata.  tabs2menu.xsl opens this,
looks up the current page's node, and displays some aspect of this
metadata as a set of tabs.


Instead of having to POLL/VOTE for the One True Meaning of Tabs, we
define a mechanism by which tabs can represent a variety of things,
including a variety of classification models.  To treat tabs as
bookmarks, just write a tabs-as-bookmarks.xsl.  For tabs that correspond
to top-level menus, write a tabs-as-toplevelmenus.xsl.  We can do both
and see which works best.



View raw message