You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Jeff Turner <je...@apache.org> on 2003/02/07 08:58:39 UTC
[POLL] Full vs. truncated menus
On Fri, Feb 07, 2003 at 05:22:09AM -0000, jefft@apache.org wrote:
> jefft 2003/02/06 21:22:08
>
> Modified: . status.xml
> src/java/components/org/apache/cocoon/transformation
> XPathTransformer.java
> Log:
> Fix a stupid bug caused (ironically) by some debugging code being committed.
...
> <release version="0.4-dev" date="unreleased">
> + <action dev="JT" type="fix" context="webapp">
> + The menu is now limited to only pages in the current subdirectory and
> + below.
> + </action>
...
This is actually quite a big change. When viewing files in
subdirectories, the menu is limited to just those items in the
subdirectory (and sub-subdirectories).
For example, see:
http://forrestbot.cocoondev.org/sites/xml-forrest/community/index.html
vs. http://xml.apache.org/forrest/community/index.html
I think in most cases, limiting the menu to the immediate context like
this makes sense. OTOH, sometimes it doesn't work out so well:
http://forrestbot.cocoondev.org/sites/xml-forrest-template/subdir/index.html
Most Forrest projects are still using book.xml, so this change has no
effect.
So a small poll for people who care..
[ ] The menu should be limited to files below the current directory
[ ] The menu should display all files in the site
If anyone can think of a way to parametrize this (sitemap behaviour),
that would be the best solution.
--Jeff
Re: [POLL] Full vs. truncated menus
Posted by "Joshua P. Dady" <jp...@indecisive.com>.
Steven Noels wrote:
> IMHO, I would opt for a mixed solution:
>
> - index page shows root content and restricted directory entries (only
> one level deep)
This is precisely something I wanted when last I had time to work on
such things - a restricted directory that would be rendered as an item
when not in that directory or as a list of stuff when you are. I also
wanted to be able to glob for entries in that menu (i.e., a menu
containing a category of function reference pages, set the entries to
"func.*.html" and have it figure out that it means the set of entries
that can be generated from func.*.xml) but that's another matter
entirely. ;)
[Snip long discussion that I'm not awake enough yet to parse]
-Josh
Re: [POLL] Full vs. truncated menus
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Steven Noels wrote:
> Sylvain Wallez wrote:
>
>> Basically, the purpose was to produce navigation and decoration on a
>> hole site composed of a hierarchy of "content" HTML pages. By
>> content, I mean that the directory structure reflects the navigation
>> tree, and that HTML is not styled. No xdoc DTD, no book.xml to update
>> : just start Mozilla composer, write your stuff in wysiwyg mode, save
>> it a the right place and it automagically appears in the navigation.
>
>
> Yeah, exactly what I have done a long-long time ago for the
> Outerthought website. I went for XML, though, but the kind of XML
> which is basically very HTMLish, and the XSLT copying across all
> undeclared/unknown elements verbatim. So I ended up editing XHTML-like
> files. Wellformedness is a hard requirement in my book though.
>
>> The navigation tree is obtained by traversing the whole tree
>> (directory generator), and getting the<title> tag of every HTML file,
>> which becomes the menu entry for that page.
>
>
> Welcome to the origin of 'yer' which has been repackaged into a Cocoon
> generator called 'libre' (mind the pun on 'book'):
> http://forrestbot.cocoondev.org/sites/xml-forrest/libre-intro.html
>
> Yer traversed directory hierarchies and generates an XML tree
> representation out of it. No caching, though, or it must be that Marc
> has added this.
I tried Libre at the time I had to do this demo, but failed to have it
generate something and gave up because of lack of time. So I ended with
some document() in XSL (yeah, you may find it ugly, but it worked).
I guess some heavy simplification of Libre could be possible when the
new Source/TraversableSource are stabilized in Excalibur (will delegate
abstraction of filesystem to the SourceResolver).
>> This navigation tree is correlated with the requested URI so that
>> parent directories are marked as "in path" and the current page as
>> "requested". This allows to display in the tree only the ancestors of
>> the current page and their siblings, along with the immediate
>> children of the current page. This also allows to easily get the path
>> to the current page (breadcrumb ?).
>
>
> Hehe - how about this collection of URLs which are collated into one
> page:
>
> page: http://outerthought.org/cocoon/gettogether/speakers
> parts: http://outerthought.org/cocoon/catoc/gettogether/speakers
> http://outerthought.org/cocoon/cayahoo/gettogether/speakers
> http://outerthought.org/cocoon/cacontent/gettogether/speakers.xml
Well, looks strangley to what I have in my demo...
> All this with only some simple page aggregation (which I consider now
> to be deprecated:
> http://blogs.cocoondev.org/stevenn/archives/000496.html (didn't
> survive the Radio->MT conversion very well).) Node hightlighting and
> expanding/collapsing done in XSLT as you describe.
I'm not considering aggregation as a wrong thing : it has the important
benefit of showing in the sitemap what parts compose the final page.
That's mainly a matter of taste, IMO.
> How very nice (and comforting) to see the coincidences in our
> approach. These were my first (not nearly) serious experiments with
> Cocoon2, dated somewhere early 2001. We're getting old :-)
Well, my demo was in october last year. I'm not that old, after all ;-))
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [POLL] Full vs. truncated menus
Posted by Steven Noels <st...@outerthought.org>.
Sylvain Wallez wrote:
> Basically, the purpose was to produce navigation and decoration on a
> hole site composed of a hierarchy of "content" HTML pages. By content, I
> mean that the directory structure reflects the navigation tree, and that
> HTML is not styled. No xdoc DTD, no book.xml to update : just start
> Mozilla composer, write your stuff in wysiwyg mode, save it a the right
> place and it automagically appears in the navigation.
Yeah, exactly what I have done a long-long time ago for the Outerthought
website. I went for XML, though, but the kind of XML which is basically
very HTMLish, and the XSLT copying across all undeclared/unknown
elements verbatim. So I ended up editing XHTML-like files.
Wellformedness is a hard requirement in my book though.
> The navigation tree is obtained by traversing the whole tree (directory
> generator), and getting the<title> tag of every HTML file, which becomes
> the menu entry for that page.
Welcome to the origin of 'yer' which has been repackaged into a Cocoon
generator called 'libre' (mind the pun on 'book'):
http://forrestbot.cocoondev.org/sites/xml-forrest/libre-intro.html
Yer traversed directory hierarchies and generates an XML tree
representation out of it. No caching, though, or it must be that Marc
has added this.
> This navigation tree is correlated with the requested URI so that parent
> directories are marked as "in path" and the current page as "requested".
> This allows to display in the tree only the ancestors of the current
> page and their siblings, along with the immediate children of the
> current page. This also allows to easily get the path to the current
> page (breadcrumb ?).
Hehe - how about this collection of URLs which are collated into one page:
page: http://outerthought.org/cocoon/gettogether/speakers
parts: http://outerthought.org/cocoon/catoc/gettogether/speakers
http://outerthought.org/cocoon/cayahoo/gettogether/speakers
http://outerthought.org/cocoon/cacontent/gettogether/speakers.xml
All this with only some simple page aggregation (which I consider now to
be deprecated: http://blogs.cocoondev.org/stevenn/archives/000496.html
(didn't survive the Radio->MT conversion very well).) Node hightlighting
and expanding/collapsing done in XSLT as you describe.
How very nice (and comforting) to see the coincidences in our approach.
These were my first (not nearly) serious experiments with Cocoon2, dated
somewhere early 2001. We're getting old :-)
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [POLL] Full vs. truncated menus
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Jeff Turner wrote:
<snip/>
>Ideally, the final menu2html.xsl stylesheet should be given the *entire*
>site menu structure, with a 'you are here' marker attribute, and be left
>to render whatever subset of the menu makes sense. If someone implements
>a snazzy CSS/JS click-to-open menu, then menu2html.xsl would populate the
>data structure with all the data.
>
I think it's time for me go out from lurking on this list, as this is
exactly what I did for a small home-grown demo. I didn't had time when I
needed that demo to dig in Forrest (shame on me), but you may find here
some useful ideas.
Basically, the purpose was to produce navigation and decoration on a
hole site composed of a hierarchy of "content" HTML pages. By content, I
mean that the directory structure reflects the navigation tree, and that
HTML is not styled. No xdoc DTD, no book.xml to update : just start
Mozilla composer, write your stuff in wysiwyg mode, save it a the right
place and it automagically appears in the navigation.
The navigation tree is obtained by traversing the whole tree (directory
generator), and getting the<title> tag of every HTML file, which becomes
the menu entry for that page.
This navigation tree is correlated with the requested URI so that parent
directories are marked as "in path" and the current page as "requested".
This allows to display in the tree only the ancestors of the current
page and their siblings, along with the immediate children of the
current page. This also allows to easily get the path to the current
page (breadcrumb ?).
As far as layout is concerned, I wrote what I call a "button-engine"
which produces SVG labels with shiny gradients for first-level
directories. Each first-level directory has an associated color that
drives the button rendering and the menu background. This makes it easy
to know in which part of the site you are.
The main problem I encountered is caching : the DirectoryGenertor being
not cacheable, the whole tree was traversed and analyzed at each
request, leading to hair-pulling response times. So I hacked a version
that reloaded the tree every "x" seconds, and recently changed it so it
_checked_ the tree every "x" seconds. This results in very smooth
operation while still allowing dynamic update.
Ah, and I also wrote once a fold/unfold menu with a few lines of JS and
ids ;-)
Tell me if all this is of interest, and I'll package something so you
can pick whatever you find good in it.
Finally :
[X] The menu should be limited to files below the current directory
[ ] The menu should display all files in the site
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [POLL] Full vs. truncated menus
Posted by Konstantin Piroumian <kp...@apache.org>.
From: "Nicola Ken Barozzi" <ni...@apache.org>
> Jeff Turner wrote, On 07/02/2003 12.28:
> > On Fri, Feb 07, 2003 at 09:23:37AM +0100, Steven Noels wrote:
> >
> >>Jeff Turner wrote:
> >>
...
> >
> > Yes, when doing all the site.xml menu stuff, I found the book.xml format
> > very constraining. It only allows two levels, <menu> and <menu-item>,
> > and as you say, the distinction (menus not being clickable) is annoying.
>
> Actually it seems that we have been using book.xml in a different way of
> what it was designed for, although I didn' tdesign it so I'm not sure ;-)
>
> I was thinking this: what if we use book.xml to define books? That is, a
> binder for chapters? In this way, the pdf generator could generate a pdf
> for every book it finds. So we can easily include books in a site.
>
> That would mean that we include two navigational sections: the book and
> the site one.
Good idea.
>
> This also means that :
>
> > In the medium term, I think we should adopt a more flexible intermediate
> > menu format, perhaps based on Maven's navigation.xml
> >
> > <project name="Maven">
> > <body>
> > ...
> > <menu name="Overview">
> > <item name="Goals" href="/goals.html"/>
> > <item name="Features" href="/features.html"/>
> > <item name="Download" href="/start/download.html"/>
> > <item name="News and Status" href="/status.html"/>
> > <item name="Getting Started" href="/start/index.html"/>
> > <item name="Reference" href="/reference/index.html">
> > <item name="Project Descriptors"
href="/reference/project-descriptor.html"/>
> > <item name="User Guide"
href="/reference/user-guide.html"/>
> > ...
>
> Which is not a bad idea.
I like it!
>
> If we need an intermediate format to render the site.xml, we might as
> well reuse that.
>
> And keep .bookxml for what it can really do.
>
> > Ideally, the final menu2html.xsl stylesheet should be given the *entire*
> > site menu structure, with a 'you are here' marker attribute, and be left
> > to render whatever subset of the menu makes sense. If someone
implements
> > a snazzy CSS/JS click-to-open menu, then menu2html.xsl would populate
the
> > data structure with all the data.
>
> That's an implementation detail, whatever will do. MAybe sending only
> the viewable nodes makes less use of bandwith, especially for large sites.
I've found my sample with show/hide menu and you can view it here:
http://cvs.apache.org/~kpiroumian/forrest/page.html
Bandwidth can be optimized if we send nodes on request. So, we can display
the top level nodes first, then if user click on a node we can download the
child node and display it dynamically. And this can be achieved by using
inline <xml> sections and JavaScript in IE. Not sure about Mozilla/Netscape,
but similar thing could be also implemented in latest versions using hidden
frames/iframes.
-- Konstantin
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
Re: [POLL] Full vs. truncated menus
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote, On 07/02/2003 12.28:
> On Fri, Feb 07, 2003 at 09:23:37AM +0100, Steven Noels wrote:
>
>>Jeff Turner wrote:
>>
>>
>>>So a small poll for people who care..
>>>
>>>[ ] The menu should be limited to files below the current directory
>>>[ ] The menu should display all files in the site
>>
>>IMHO, I would opt for a mixed solution:
>>
>> - index page shows root content and restricted directory entries (only
>>one level deep)
>> - directory pages show directory content and root directories
...
>>What do you think?
>
>
> Yes, when doing all the site.xml menu stuff, I found the book.xml format
> very constraining. It only allows two levels, <menu> and <menu-item>,
> and as you say, the distinction (menus not being clickable) is annoying.
Actually it seems that we have been using book.xml in a different way of
what it was designed for, although I didn' tdesign it so I'm not sure ;-)
I was thinking this: what if we use book.xml to define books? That is, a
binder for chapters? In this way, the pdf generator could generate a pdf
for every book it finds. So we can easily include books in a site.
That would mean that we include two navigational sections: the book and
the site one.
This also means that :
> In the medium term, I think we should adopt a more flexible intermediate
> menu format, perhaps based on Maven's navigation.xml
>
> <project name="Maven">
> <body>
> ...
> <menu name="Overview">
> <item name="Goals" href="/goals.html"/>
> <item name="Features" href="/features.html"/>
> <item name="Download" href="/start/download.html"/>
> <item name="News and Status" href="/status.html"/>
> <item name="Getting Started" href="/start/index.html"/>
> <item name="Reference" href="/reference/index.html">
> <item name="Project Descriptors" href="/reference/project-descriptor.html"/>
> <item name="User Guide" href="/reference/user-guide.html"/>
> ...
Which is not a bad idea.
If we need an intermediate format to render the site.xml, we might as
well reuse that.
And keep .bookxml for what it can really do.
> Ideally, the final menu2html.xsl stylesheet should be given the *entire*
> site menu structure, with a 'you are here' marker attribute, and be left
> to render whatever subset of the menu makes sense. If someone implements
> a snazzy CSS/JS click-to-open menu, then menu2html.xsl would populate the
> data structure with all the data.
That's an implementation detail, whatever will do. MAybe sending only
the viewable nodes makes less use of bandwith, especially for large sites.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [POLL] Full vs. truncated menus
Posted by Jeff Turner <je...@apache.org>.
On Fri, Feb 07, 2003 at 09:23:37AM +0100, Steven Noels wrote:
> Jeff Turner wrote:
>
> >So a small poll for people who care..
> >
> >[ ] The menu should be limited to files below the current directory
> >[ ] The menu should display all files in the site
>
> IMHO, I would opt for a mixed solution:
>
> - index page shows root content and restricted directory entries (only
> one level deep)
> - directory pages show directory content and root directories
That sounds ideal to me too, and something to aim for. The poll is just
about optimizing the present mess as far as possible.
...
> directory pages:
>
> * About
> * Getting involved
> * Documentation
> * Some Samples
> * Community
> o About
> o How-To Samples
> + Overview
> + Single Page
> + Multi-Page
> # Intro
> # Step 1
> # Step 2
> # Step 3
> # Step 4
> # Step 5
> + With Images
> o Committers
> + CVS through SSH
> * References
>
> ... which brings me to the long-lasting itch why we can't make <menu
> label>s make direct links:
>
> # About -> really points to Index in this case
> * License
> * Download
> * Who we are
> * Dream list
> * FAQs
> * Changes
> * Todo
> * Live sites
>
> What do you think?
Yes, when doing all the site.xml menu stuff, I found the book.xml format
very constraining. It only allows two levels, <menu> and <menu-item>,
and as you say, the distinction (menus not being clickable) is annoying.
In the medium term, I think we should adopt a more flexible intermediate
menu format, perhaps based on Maven's navigation.xml
<project name="Maven">
<body>
...
<menu name="Overview">
<item name="Goals" href="/goals.html"/>
<item name="Features" href="/features.html"/>
<item name="Download" href="/start/download.html"/>
<item name="News and Status" href="/status.html"/>
<item name="Getting Started" href="/start/index.html"/>
<item name="Reference" href="/reference/index.html">
<item name="Project Descriptors" href="/reference/project-descriptor.html"/>
<item name="User Guide" href="/reference/user-guide.html"/>
...
Ideally, the final menu2html.xsl stylesheet should be given the *entire*
site menu structure, with a 'you are here' marker attribute, and be left
to render whatever subset of the menu makes sense. If someone implements
a snazzy CSS/JS click-to-open menu, then menu2html.xsl would populate the
data structure with all the data.
--Jeff
> </Steven>
> --
> Steven Noels http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> Read my weblog at http://blogs.cocoondev.org/stevenn/
> stevenn at outerthought.org stevenn at apache.org
>
Re: [POLL] Full vs. truncated menus
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Steven Noels wrote, On 07/02/2003 9.23:
> Jeff Turner wrote:
>
>> So a small poll for people who care..
>>
>> [ ] The menu should be limited to files below the current directory
>> [ ] The menu should display all files in the site
>
>
> IMHO, I would opt for a mixed solution:
[snipped explanation]
> What do you think?
I think it's sweet. Basically keeps the best of both worlds: smaller
menus without overloading and still keep contextual information.
That's a +0 though, I don't really know how to do it I think ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [POLL] Full vs. truncated menus
Posted by Steven Noels <st...@outerthought.org>.
Jeff Turner wrote:
> So a small poll for people who care..
>
> [ ] The menu should be limited to files below the current directory
> [ ] The menu should display all files in the site
IMHO, I would opt for a mixed solution:
- index page shows root content and restricted directory entries (only
one level deep)
- directory pages show directory content and root directories
index:
* About
o Index
o License
o Download
o Who we are
o Dream list
o FAQs
o Changes
o Todo
o Live sites
* Getting Involved
o Contributing
o CVS
o Mail lists
o Mail Archives
o Bugs and Issues
o Open Issues
* Documentation
o Forrest Primer
o Our Contract
o The Forrestbot
o Using Forrest
o XML Validation
o Menus and Linking
o Standards Compliance
o Libre
o DTD documentation
o Sourcetype Action
o The ForrestBar
* Some Samples
o document-v11
o How-Tos
* Community
o About
o How-To Samples
o Committers
* References
o Apache Gump
o Apache Cocoon
o Krysalis Centipede
directory pages:
* About
* Getting involved
* Documentation
* Some Samples
* Community
o About
o How-To Samples
+ Overview
+ Single Page
+ Multi-Page
# Intro
# Step 1
# Step 2
# Step 3
# Step 4
# Step 5
+ With Images
o Committers
+ CVS through SSH
* References
... which brings me to the long-lasting itch why we can't make <menu
label>s make direct links:
# About -> really points to Index in this case
* License
* Download
* Who we are
* Dream list
* FAQs
* Changes
* Todo
* Live sites
What do you think?
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org