You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Dave Brondsema <da...@brondsema.net> on 2004/01/13 22:21:09 UTC
Re: tabs.xml into site.xml
Quoting Ross Gardler <rg...@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? How
would this work? Recognize a special "tabs" node like we do for "external-refs"?
--
Dave Brondsema
dave@brondsema.net
http://www.brondsema.net - personal
http://www.splike.com - programming
http://csx.calvin.edu - student org
Re: tabs.xml into site.xml
Posted by Ross Gardler <rg...@apache.org>.
Johan Kok wrote:
>
>
> Ross Gardler wrote:
>
>>
>> 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?
>
>
> An earlier message of mine may have pulled a dissapearance trick. ---
>
> Why not consider tabs as a nagivation method, menus another, if we add
> slide controls, consider that as yet another. The key would be to
> consider the relationship between different methods and/or to have a
> method of describing that if existing, including synchronisation between
> these if they happen to control the same areas, e.g. slide forward and
> next page in menu or next tab. In this way the various forms of
> navigation methods may even be defined seperately, e.g. having 2 or
> even 3 tab levels, while having the balance in a menu or even from the
> 2 level in the menu (duplications between menus and tabs).
I agree they are all different navigation methods, therefore they all
belong in a single navigation file (at least in my mind). So...
> My real question is: Why does one have to be limited by a single
> restrictive strategy? --- Make it flexible, with an option which one
> wants to use,
At first I typed a perfectly reasonable justification illustrating that
my aproach is not restrictive - however, during "reading before posting"
I realised something...
I think I may be getting caught up in trying to create a clever design
for the intermediate format when really I should be focussing on a
clever design for my source format (or better still adopting one but
that's a different story). The intermediate format will be automatically
generted by Forrest so I don't really care if it is one file or ten, as
long as it serves it's purpose.
If others find having to maintain both site.xml and tab.xml (or a joined
version of the two) tiresome then they should, like me, adopt a
different source format that removes this need.
So I am now +0 for just embedding the existing tabs.xml into site.xml.
(+0 because with my new found clarity I don't care how many navigation
files there are!) In the future I may implement this but not right now.
Ross
Re: tabs.xml into site.xml
Posted by Johan Kok <jk...@messianic.dyndns.org>.
Ross Gardler wrote:
>
> 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?
An earlier message of mine may have pulled a dissapearance trick. ---
Why not consider tabs as a nagivation method, menus another, if we add
slide controls, consider that as yet another. The key would be to
consider the relationship between different methods and/or to have a
method of describing that if existing, including synchronisation between
these if they happen to control the same areas, e.g. slide forward and
next page in menu or next tab. In this way the various forms of
navigation methods may even be defined seperately, e.g. having 2 or
even 3 tab levels, while having the balance in a menu or even from the
2 level in the menu (duplications between menus and tabs).
My real question is: Why does one have to be limited by a single
restrictive strategy? --- Make it flexible, with an option which one
wants to use, i.e. a flag to have tabs or not, or within a relationship
indicator within tabs to have the first level of the document hierarchy
only and in the menu definition state that the menu wil only start at
the 2nd level of the document hierarchy. At this time one can even add
for example a slide show which cover all of the document hierarchy as
well. Each of these navigation methods could be on or off.
Regards
Johan Kok
Re: tabs.xml into site.xml
Posted by Ross Gardler <rg...@apache.org>.
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"/>
</b>
</a>
<e label="e" dir="e">
<f label="f" href="f.html"/>
</e>
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"/>
</tab>
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 -->
</courseA1>
<courseA2 label="CourseA2 href="index.html">
<!-- course pages -->
</courseA2>
<courseB1 label="CourseB1" href="index.html">
<!-- course pages -->
</courseB1>
<courseB2 label="CourseB2 href="index.html">
<!-- course pages -->
</courseB2>
</courses>
<orgAProfile label="Facilitator" dir="profile_orgA" tab="courseA1,
courseA2">
<!-- profile pages for organistion A -->
</orgA>
<orgB label="Facilitator" dir="profile_orgB" tab="courseB1, courseB2">
<!-- profile pages for organistion B -->
</orgB>
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?
Ross
Re: tabs.xml into site.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: tabs.xml into site.xml
Posted by Ross Gardler <rg...@apache.org>.
Dave Brondsema wrote:
> Quoting Ross Gardler <rg...@apache.org>:
>
>
>>Dave Brondsema wrote:
>>
>>>Quoting Ross Gardler <rg...@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
Re: tabs.xml into site.xml
Posted by Dave Brondsema <da...@brondsema.net>.
Quoting Ross Gardler <rg...@apache.org>:
> Dave Brondsema wrote:
> > Quoting Ross Gardler <rg...@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?
> How
> > would this work? Recognize a special "tabs" node like we do for
> "external-refs"?
>
> Well it hasn;t been discussed fully yet, just hinted at by Nicola Ken
> and agreed as a good idea by myself. Obviously with such a change
> discussion should be had first - so lets go...
>
> Here's the original (minimal) thread, not really a discussion, just a
> couple of comments:
> http://marc.theaimsgroup.com/?l=forrest-dev&m=107208737624502&w=2
>
> This may have been discussed previously too
>
> 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)
> Nicola Kens original suggestion (in above thread) was:
>
> "My idea was to have top-level nodes of site.xml be the tabs, and a skin
> could decide at which level switch from tabs to navigation. As some
> pointed out, tabs are not necessarily containers of pages, but links to
> pages. Hence they have to remain in a separate hierarchy. This does not
> mean though that they have to be in a separate file."
>
> Now I don't claim to know exactly what Nicola Ken was thinking but my
> thinking is that we can create some default behaviour that has top level
> nodes become tabs, and then a defined number of levels below that be
> "sub tabs". How these are displayed is up to the skin. They could even
> be ignored and just have a left menu bar. In my skin I want to get rid
> of the left menu bar and use a two level tab system with a drop down
> menu for the rest (I need the full width of the screen for content).
I think for most people (at least for me), their sites have a tab corresponding
to each top-level node. So this as the default would make sense.
>
> 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.
The current xml structure used in tabs.xml makes sense; I don't think it would
integrate with the site.xml structure very well.
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
> 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) and
determine if a given page is part of a tab section (i.e. the tab needs to be
highlighted) with url matching. Example:
<tab label="Foobar Docs" href="foobar/docs"/>
A file like foobar/docs/faq.html would succesfully match against the href and so
the "Foobar Docs" tab would be highlighted.
> 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.
--
Dave Brondsema
dave@brondsema.net
http://www.brondsema.net - personal
http://www.splike.com - programming
http://csx.calvin.edu - student org
Re: tabs.xml into site.xml
Posted by Ross Gardler <rg...@apache.org>.
Dave Brondsema wrote:
> Quoting Ross Gardler <rg...@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? How
> would this work? Recognize a special "tabs" node like we do for "external-refs"?
Well it hasn;t been discussed fully yet, just hinted at by Nicola Ken
and agreed as a good idea by myself. Obviously with such a change
discussion should be had first - so lets go...
Here's the original (minimal) thread, not really a discussion, just a
couple of comments:
http://marc.theaimsgroup.com/?l=forrest-dev&m=107208737624502&w=2
This may have been discussed previously too
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.
Nicola Kens original suggestion (in above thread) was:
"My idea was to have top-level nodes of site.xml be the tabs, and a skin
could decide at which level switch from tabs to navigation. As some
pointed out, tabs are not necessarily containers of pages, but links to
pages. Hence they have to remain in a separate hierarchy. This does not
mean though that they have to be in a separate file."
Now I don't claim to know exactly what Nicola Ken was thinking but my
thinking is that we can create some default behaviour that has top level
nodes become tabs, and then a defined number of levels below that be
"sub tabs". How these are displayed is up to the skin. They could even
be ignored and just have a left menu bar. In my skin I want to get rid
of the left menu bar and use a two level tab system with a drop down
menu for the rest (I need the full width of the screen for content).
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?
<docs label="Documentation" dir="docs" indexfile="index.html" tab="Docs">
...
</docs>
Would produce a tab labelled "Docs" that links to "docs/index.html".
No value for "tab" means use the same label as for the menu item, so:
<docs label="Documentation" dir="docs" indexfile="index.html">
...
</docs>
produces a tab with the label "Documentation", linked to "docs/index.html"
We can also provide something like a "noTab" attribute that indicates
the menu element should not generate a corresponding tab, so:
<docs label="Documentation" dir="docs" noTab="true">
...
</docs>
produces a menu element but no tab.
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.
Perhaps Nicola Ken had a different idea when he dropped that innocent
comment into his mail...
Ross