forrest-dev mailing list archives

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