forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: tabs.xml into site.xml
Date Wed, 14 Jan 2004 20:50:59 GMT
Nicola Ken Barozzi wrote:
> Ross Gardler wrote:
>> Dave Brondsema wrote:
> ...
>>> My thoughts overall: keep tabs.xml since it is serving it's purpose
>>> well (and backwards compatibility). The only functionality that I
>>> think we should add is default tabs (no tabs.xml file) that take
>>> each top-level node of the site.xml
>> How about allowing a locally defined tabs.xml file to override the 
>> autogenerated version. This maintains backward compatability and 
>> removes the *requirement* to maintain two separate files.
> As it has been noted by many, tabs are not necessarily containers of 
> pages, but may be used more like bookmarks.
> Hence what I would propose to do is:
> 1 - add a <tabs> section in site.xml where tabs can be placed, instead
>     of tabs.xml (which remains as an option)
> 2 - make it possible to generate tabs even without a section by just
>     defining an attribute in skinconf that enables the first levels
>     to be used as tabs (more difficult to do but possible)
> Both points can be done while preserving back-compat.

Well this is certainly an improvement over two separate files,  but it 
still requires duplication of information, at least in the vast majority 
(if not all) of my use cases.

Is there any reason for not liking my approach? We can still use tabs 
like a bookmark, by making the top level tab the first in the hierarchy 
that defines a tab and changing the proposed noTab attribute to showTab. 
Default behaviour would be showTab is true for directories, false for 
hrefs (could be confusing, alternative is true for directories, false 
for files), thus:

<a label="a" dir="a" showTab="false">
   <b label="b" dir="b" showtab="false">
     <c label="c" href="index.html" showTab="true"/>
     <d label="d" href="d.html"/>

<e label="e" dir="e">
   <f label="f" href="f.html"/>

would give us the equivalent tab file of:

<tab label="c" href="/a/b/index.html"/>
<tab label="e" dir="e">
   <tab label="f" href="e/f.html"/>

I have spotted a draw back to my approach though, but the solution may 
solve another itch that has been emerging:

Using my scheme, as defined so far, it is not possible have multiple 
elements in the site.xml file assigned to a single tab. This is because 
if we define two elements with the same value in the tab attribute we 
would not know which was the one to link to when the tab is clicked on.

The "emerging" itch I have is that I want to display a number of 
sections of site.xml when one of a group of tabs is selected but not 
when others are selected. For example, suppose someone has a site of 
course materials, they present courses at two different institutions. 
They want the same contact details and profile to appear for each course 
at any given organisation. So they have 2 profiles sections, one for 
each organisation.

At the moment they have to maintain these profile sections in each of 
the places I want them to appear, what I'd rather they did would be to 
define them once and then list the tabs they should appear on.

The solution to the my emerging itch (using my proposed schema for 
site.xml+tabs.xml, but alternatives considered:

<courses label="courses" dir="courses">
   <courseA1 label="CourseA1" href="index.html">
     <!-- course pages -->
   <courseA2 label="CourseA2 href="index.html">
     <!-- course pages -->

   <courseB1 label="CourseB1" href="index.html">
     <!-- course pages -->
   <courseB2 label="CourseB2 href="index.html">
     <!-- course pages -->

<orgAProfile label="Facilitator" dir="profile_orgA" tab="courseA1, 
   <!-- profile pages for organistion A -->

<orgB label="Facilitator" dir="profile_orgB" tab="courseB1, courseB2">
   <!-- profile pages for organistion B -->

The problem still remains as to which of these elements defines course 
A1, courseA2 etc. is it the CourseA1 element or the orgAProfile element? 
We could sa the first place it is defined is where it is selected, or we 
could have an indexfile type attribute. But it feels a little messy to me.

Any other ideas, or am I still on the wrong track?


View raw message