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 22:11:36 GMT
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.


View raw message