forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: Menu Overhead Problem (and an offer to fix it)
Date Mon, 21 Nov 2005 05:42:22 GMT
Ross Gardler wrote:
> Ferdinand Soethe wrote:
> >>I didn't really follow the example. It would be easier for me to grasp
> >>if you gave an example of what you get with default Forrest and an 
> >>example of what you want.
> >
> >Atm when I navigate to a page that is not visible part of a menu (for
> >example by following a link within a page), I'm currently loosing
> >context because the menues will collapse.
> >
> >What I want is to maintain context without creating a permanent menu entry
> >for every page in a site.
> OK, I got it that time :-).
> >>What "type" attribute? site.xml doesn't have one does it?
> >
> >Well I found it in the book2menu transformation for menuitems that
> >don't show. So it does exist.
> Interesting. I've never used it. I think this is legacy stuff, probably 
> from the original book.xml file.

No it is not legacy. The site.xml is converted internally
to the "book" structure.

> Actually, this reminds me of a feature you may not know about. You can 
> add a book.xml file into a directory and that will be used instead of 
> site.xml. So you can have a menu that will only display when a file in 
> that directory is being displayed.
> >>Why not a (seemingly) more appropriate attribute name, say show, which
> >>can then take the values:
> >
> >Wouldn't matter to me, I just wanted to stick with already established
> >mechnisms and type is not too bad.
> I think we ought to figure out why the type attribute is present before 
> we start trying to reuse it for a different purpose. It may cause real 
> problems with backward compatability somewhere.
> Can anyone tell us what @type is used for?

No sorry. Someone would need to investigate the sitemaps
and xsl files.

Perhaps the "type" attribute is described in Jeff's
original RT, which is linked from

> >>Also, isn't the overhead a little high here? Do we have to define this
> >>attribute for all pages that fit into your "don't display unless 
> >>selected" category. Or is the intention that we can define it for groups
> >>as well:
> >
> >Not a bad idea but certainly a second step that requires some more
> >modifications. And it would have to be something like
> >ShowChildrenOnlyWhenCurrent because you don't actually want to hide
> >menus themselves, would you?
> Yes, that would be right.
> >>If you have a use case and it is an *optional* attribute then I have no
> >>objection, I'm just not sure of the attribute name. The enhancements I
> >>suggest can come if someone needs them.
> >
> >I do and they are completely optional.
> >
> >So I'll check these changes into version 0.7x and create a demo in
> >freshsite. And unless someone has really strong feelings about the
> >naming, I'll stick with the type attribute for now.
> Hmmm... that means a new feature in the 0.7 branch, we are only doing 
> bug fixes in 0.7 aren't we?

I too am concerned about this trend. The branch is for
fixing important issues that were discovered with the release,
and not for new features. We would do better to put this
into trunk and work on releasing 0.8 asap.

Perhaps this could be seen as a bugfix. So i don't
know what to suggest.

Whatever happens Ferdinand, please make those changes
in 0.8-dev first. When we are happy with it there then
we can decide whether to add it to 0.7 branch. The latter
should not be seen as a "development" area.


View raw message