forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: tabs.xml into site.xml
Date Wed, 14 Jan 2004 06:46:04 GMT
Dave Brondsema wrote:
> Quoting Ross Gardler <rgardler@apache.org>:
> 
> 
>>Dave Brondsema wrote:
>>
>>>Quoting Ross Gardler <rgardler@apache.org>:
>>>
>>>
>>>
>>>>Having said that, maybe the tabs.xml generated from site.xml thing can 
>>>>go in 0.6 since we have introduced two level tabs now. Comments?
>>>>
>>>
>>>
>>>Can you point to a thread where this was discussed?  Why do we want this?
>>

<snip/>

>>My reasoning for wanting to do this is that site.xml and tabs.xml both 
>>describe navigation through the site and therefore they should both be 
>>in the same file.
>>
> 
> 
> Makes sense.  (but see later, I don't think the structures meld well)
> 

<snip/>

> 
>>At the moment we relate sections of site.xml to tabs defined in a 
>>separate file using the "tab" attribute in site.xml and the "is" 
>>attibute in the tabs.xml file. Why not just define the tab label in the 
>>site.xml file?
> 
> 
> This wouldn't allow for a tab to have an href to a external page.  It also
> wouldn't allow for ordering and I'm not sure how subtabs would work.

External page:

<external label="External Link" href="http://www.foo.com" tab="External"/>

Subtabs:

<topLevel label="top level tab" dir="a" tab="top">
   <secondLevel label="second level tab" dir="b" tab="second">
      <thirdLevel label="third level tab" href="third.html"/>
   </secondLevel>
</topLevel>

ordering would be as now - first in site.xml (currently tabs.xml) is 
first in the ordering. This does cause a problem if you want your tabs 
in a different order to your menu, but I can't think of a use case for 
this at present. If one emerges we could provide a "tabOrder" attribute.

> The current xml structure used in tabs.xml makes sense; I don't think it would
> integrate with the site.xml structure very well.

It does make sense I agree. But in most cases (at least most of my 
cases) it is a duplication of information, and I hate having to maintain 
things in two places.

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

>>At the moment we relate sections of site.xml to tabs defined in a 
>>separate file using the "tab" attribute in site.xml and the "is" 
>>attibute in the tabs.xml file. Why not just define the tab label in the 
>>site.xml file?
> 
> 
> Or, we could get rid of @tab and @id (and use @href instead of @dir too)

[Aside: @href and @dir have different functions see the comments in 
http://cvs.apache.org/viewcvs.cgi/xml-forrest/src/core/fresh-site/src/documentation/content/xdocs/tabs.xml?rev=1.3&view=markup]

> and
> determine if a given page is part of a tab section (i.e. the tab needs to be
> highlighted) with url matching.  

Actually, this is how the selected tab is found. The ID is used to 
decide which elements in site.xml are displayed in the menu when a 
particular tab is selected.

>>The big probelm with this approach is that it is not backward 
>>compatible. We can make it so by creating a new site.xml schema and 
>>processing in the sitemap appropriately (performance hit). But then I'm 
>>not sure of any way we can do it and keep backward compatability.
>>
> 
> 
> site.xml doesn't have a schema.  It is (for better or worse) very free-form.

Yes, you are quite right - that makes it impossible to provide backward 
compatability unless we keep tab.xml as an override mechanism.

Ross


Mime
View raw message