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/08/01 15:25:12 UTC
Re: Menu questions
On Thu, Jul 31, 2003 at 05:32:47PM -0400, Brett Presnell wrote:
>
> Maybe I shouldn't be using forrest for this project (website for an
> academic department), but anyway ...
>
> Is it possible to have a page contain a menu without appearing in the
> menu. What I have in mind is something like the following. Say I have
>
> subdir/index.xml
> subdir/file01.xml
> subdir/file02.xml
> ...
> subdir/file50.xml
>
> with index.xml containing links to each of the file??.xml.
>
> I would like to be able to click on the link to file01.html and have
> it come up basically with the same menu and tabs that I see when I'm
> viewing index.html. I thought this might just happen automatically
> ifI left all the file??.xml's out of site.xml, but it doesn't. I've
> tried all kinds of contortions with site.xml and tabs.xml (using a CVS
> version of Forrest from within the last 24 hours), but I can't manage
> to make it happen.
>
> Anyway, if it's not possible, that's ok. If it is, how do I make it
> work?
Anything is possible, given enough tinkering with the sitemaps.
How does this look:
http://cvs.apache.org/~jefft/forrest/samples/hidden-menus-site/
It's a modified 'forrest seed' site, where page[1-5].html pages have a
customized menu, showing their page*.html peers and index.html 'parent';
for example:
http://cvs.apache.org/~jefft/forrest/samples/hidden-menus-site/page1.html
Is this more or less what you're after?
The webapp source available at:
http://cvs.apache.org/~jefft/forrest/samples/hidden-menus.tgz
The custom menu for page*.html pages was done by adding an extra matcher
to sitemap.xmap, just before the default **book-*.html matcher:
302 <!-- ADDED -->
303 <map:match pattern="**book-page*.html">
304 <map:generate src="content/xdocs/book-index.xml"/>
305 <map:serialize type="xml"/>
306 </map:match>
307 <!-- /ADDED -->
308
309 <map:match pattern="**book-*.html">
310 <map:mount uri-prefix="" src="menu.xmap" check-reload="yes" />
311 </map:match>
312
Where book-index.xml is just a saved copy of XML from URL
book-index.html, modified to include the extra menu items.
A few auxiliary changes were also needed:
- In forrest.properties, I had to exclude book-index.xml from
validation:
forrest.validate.xdocs.excludes=site.xml,book-index.xml
- By default, the forrest-site skin's book2menu.xsl treated the
'index.html' link as a menu, and therefore not clickable. I overrode
the book2menu.xsl stylesheet to make any element with a href attribute
clickable:
--- /home/jeff/apache/xml/xml-forrest/src/resources/skins/forrest-site/xslt/html/book2menu.xsl 2003-03-26 23:55:07.000000000 +1100
+++ src/documentation/skins/forrest-site/xslt/html/book2menu.xsl 2003-08-01 23:03:24.000000000 +1000
@@ -18,7 +18,12 @@
<xsl:template match="menu">
<li>
- <font color="#CFDCED"><xsl:value-of select="@label"/></font>
+ <xsl:if test="@href and not(contains(@href, '/'))">
+ <a href="{@href}"><xsl:value-of select="@label"/></a>
+ </xsl:if>
+ <xsl:if test="not(@href)">
+ <font color="#CFDCED"><xsl:value-of select="@label"/></font>
+ </xsl:if>
<ul>
<xsl:apply-templates/>
</ul>
--Jeff
> --
> Brett Presnell
> Department of Statistics
> University of Florida
> http://www.stat.ufl.edu/~presnell/
>
> "We don't think that the popularity of an error makes it the truth."
> -- Richard Stallman
Re: Menu questions
Posted by Jeff Turner <je...@apache.org>.
On Tue, Aug 19, 2003 at 12:00:33PM -0400, Brett Presnell wrote:
>
> As a reminder, I've appended the last message that I have saved from
> this thread. Has there been any more discussion of this issue? It
> would be great if these features were implemented in forrest in some
> way that would not require modification of forrest source files
> whenever forrest is upgraded (or at least to avoid having to check
> that source files have not otherwise changed). I guess I'm
> indifferent to whether the solution is xml or javascript or both, but
> I agree that it would ideally be configurable through site.xml and
> skinconf.xml.
I agree, it would be nice. I've created a bugreport to track this:
http://issues.cocoondev.org/jira/secure/ViewIssue.jspa?id=10114
Patches welcome.
> I imagine that you all are very aware of this, but the issue of
> separation of user options/additions from forrest source also comes up
> in the "adding content" arena. Quoting the documentation
>
> If your site defines its own sitemap, it must perform all the
> operations of the Forrest default. To get started, simply copy the
> Forrest sitemaps from xml-forrest/src/resources/conf/*.xmap into
> your src/documentation directory (or wherever ${project.sitemap-dir}
> points to).
>
> It would be helpful if one could just define local versions of
> forrest.xmap, sitemap.xmap, etc that would contain only the local
> additions and/or overrides of forrest defaults. Of course I really
> have no idea of the technical difficulties involved with making this
> happen. I guess I just want to reinforce the idea that a complete
> separation of forrest source files from user config/source files is an
> important issue (I'm not sure how it ranks with separation of content
> from presentation, but it's up there for me).
It is a problem. Every time I update Forrest, I spend a bit of time
synching the Forrest sitemap with mine. Without 'vim -d' I don't know
how I'd manage it.
I don't have any solution in mind. Perhaps the Cocoon people will ride
to the rescue with blocks.
> BTW, just to be clear, I am definitely not unappreciative of anything
> that anyone here is doing. Forrest is great and Jeff's solution to my
> original problem does exactly what I wanted, and I'm really grateful
> for all of it! Please do keep up the good work.
Suggestions, criticisms, random thoughts etc, always welcome.
--Jeff
> --
> Brett Presnell
> Department of Statistics
> University of Florida
> http://www.stat.ufl.edu/~presnell/
>
> "We don't think that the popularity of an error makes it the truth."
> -- Richard Stallman
>
>
> In message <bg...@main.gmane.org> Nicola Ken Barozzi writes:
> >
> > Jeff Turner wrote, On 05/08/2003 14.57:
> >
> > > On Tue, Aug 05, 2003 at 12:11:15PM +0200, Nicola Ken Barozzi wrote:
> > ...
> > >>How different is this from my JS version of the collapsed menus?
> > >
> > > Two differences:
> > >
> > > 1) index.html had no visible child pages. In JS, it would.
> >
> > Hmmm, it wouldn't IIUC if we made it configurable if we wanted some
> > entries open at the beginning, like a (openmenus=all|none|first) in
> > skinconf.
> >
> > For example, we would have:
> >
> > <openmenus>none</openmenus>
> >
> > and the first page will not show any opne menus.
> >
> > > 2) The parent entry in the menu, 'Index', loads a page when clicked. In
> > > JS, the entry would trigger an open/close action, not load a page.
> > >
> > > http://cvs.apache.org/~jefft/forrest/samples/hidden-menus-site/
> > >
> > > This is a minor limitation with the JS, that menu entries cannot double
> > > as both page links and parents of other entries. Either a menu entry is
> > > a page link, or an open/close menu category.
> >
> > Not necessarily, this is what the current JS does, but it can be easily
> > amended. If it also links to a page, there is no need to use javascript
> > at all, as the linked page will simply show the "opened" version. Now
> > that I think of it, it should already work, have to try it.
> >
> > I'm just trying to unify the menu-handling approach to one only, so that
> > we don't overlap, and maybe we have less work to do.
> >
> > What should we do?
> >
> > 1 - keep both implementations with common config semantics
> > 2 - keep only the javascript version
> >
> > IMHO two seems better from a quick thought, as it's faster to implement,
> > easier to maintain, and more flashy, but I'm fine with either solution
> > or even other solutions (like a @open attribute in site.xml, but would
> > have to think how to do it).
> >
> > --
> > Nicola Ken Barozzi nicolaken@apache.org
> > - verba volant, scripta manent -
> > (discussions get forgotten, just code remains)
> > ---------------------------------------------------------------------
Re: Menu questions
Posted by Brett Presnell <pr...@stat.ufl.edu>.
As a reminder, I've appended the last message that I have saved from
this thread. Has there been any more discussion of this issue? It
would be great if these features were implemented in forrest in some
way that would not require modification of forrest source files
whenever forrest is upgraded (or at least to avoid having to check
that source files have not otherwise changed). I guess I'm
indifferent to whether the solution is xml or javascript or both, but
I agree that it would ideally be configurable through site.xml and
skinconf.xml.
I imagine that you all are very aware of this, but the issue of
separation of user options/additions from forrest source also comes up
in the "adding content" arena. Quoting the documentation
If your site defines its own sitemap, it must perform all the
operations of the Forrest default. To get started, simply copy the
Forrest sitemaps from xml-forrest/src/resources/conf/*.xmap into
your src/documentation directory (or wherever ${project.sitemap-dir}
points to).
It would be helpful if one could just define local versions of
forrest.xmap, sitemap.xmap, etc that would contain only the local
additions and/or overrides of forrest defaults. Of course I really
have no idea of the technical difficulties involved with making this
happen. I guess I just want to reinforce the idea that a complete
separation of forrest source files from user config/source files is an
important issue (I'm not sure how it ranks with separation of content
from presentation, but it's up there for me).
BTW, just to be clear, I am definitely not unappreciative of anything
that anyone here is doing. Forrest is great and Jeff's solution to my
original problem does exactly what I wanted, and I'm really grateful
for all of it! Please do keep up the good work.
--
Brett Presnell
Department of Statistics
University of Florida
http://www.stat.ufl.edu/~presnell/
"We don't think that the popularity of an error makes it the truth."
-- Richard Stallman
In message <bg...@main.gmane.org> Nicola Ken Barozzi writes:
>
> Jeff Turner wrote, On 05/08/2003 14.57:
>
> > On Tue, Aug 05, 2003 at 12:11:15PM +0200, Nicola Ken Barozzi wrote:
> ...
> >>How different is this from my JS version of the collapsed menus?
> >
> > Two differences:
> >
> > 1) index.html had no visible child pages. In JS, it would.
>
> Hmmm, it wouldn't IIUC if we made it configurable if we wanted some
> entries open at the beginning, like a (openmenus=all|none|first) in
> skinconf.
>
> For example, we would have:
>
> <openmenus>none</openmenus>
>
> and the first page will not show any opne menus.
>
> > 2) The parent entry in the menu, 'Index', loads a page when clicked. In
> > JS, the entry would trigger an open/close action, not load a page.
> >
> > http://cvs.apache.org/~jefft/forrest/samples/hidden-menus-site/
> >
> > This is a minor limitation with the JS, that menu entries cannot double
> > as both page links and parents of other entries. Either a menu entry is
> > a page link, or an open/close menu category.
>
> Not necessarily, this is what the current JS does, but it can be easily
> amended. If it also links to a page, there is no need to use javascript
> at all, as the linked page will simply show the "opened" version. Now
> that I think of it, it should already work, have to try it.
>
> I'm just trying to unify the menu-handling approach to one only, so that
> we don't overlap, and maybe we have less work to do.
>
> What should we do?
>
> 1 - keep both implementations with common config semantics
> 2 - keep only the javascript version
>
> IMHO two seems better from a quick thought, as it's faster to implement,
> easier to maintain, and more flashy, but I'm fine with either solution
> or even other solutions (like a @open attribute in site.xml, but would
> have to think how to do it).
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
Re: Menu questions
Posted by Dave Brondsema <da...@brondsema.net>.
>
> I'm just trying to unify the menu-handling approach to one only, so that
> we don't overlap, and maybe we have less work to do.
>
> What should we do?
>
> 1 - keep both implementations with common config semantics
> 2 - keep only the javascript version
>
> IMHO two seems better from a quick thought, as it's faster to implement,
> easier to maintain, and more flashy, but I'm fine with either solution
> or even other solutions (like a @open attribute in site.xml, but would
> have to think how to do it).
Configurable. Already we see a few different, but equally good options. It may be a bit more coding now, but I say we put the decision in the hands of the user.
Dave Brondsema
dave@brondsema.net
http://www.brondsema.net - personal
http://www.splike.com - programming
Re: Menu questions
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote, On 05/08/2003 14.57:
> On Tue, Aug 05, 2003 at 12:11:15PM +0200, Nicola Ken Barozzi wrote:
...
>>How different is this from my JS version of the collapsed menus?
>
> Two differences:
>
> 1) index.html had no visible child pages. In JS, it would.
Hmmm, it wouldn't IIUC if we made it configurable if we wanted some
entries open at the beginning, like a (openmenus=all|none|first) in
skinconf.
For example, we would have:
<openmenus>none</openmenus>
and the first page will not show any opne menus.
> 2) The parent entry in the menu, 'Index', loads a page when clicked. In
> JS, the entry would trigger an open/close action, not load a page.
>
> http://cvs.apache.org/~jefft/forrest/samples/hidden-menus-site/
>
> This is a minor limitation with the JS, that menu entries cannot double
> as both page links and parents of other entries. Either a menu entry is
> a page link, or an open/close menu category.
Not necessarily, this is what the current JS does, but it can be easily
amended. If it also links to a page, there is no need to use javascript
at all, as the linked page will simply show the "opened" version. Now
that I think of it, it should already work, have to try it.
I'm just trying to unify the menu-handling approach to one only, so that
we don't overlap, and maybe we have less work to do.
What should we do?
1 - keep both implementations with common config semantics
2 - keep only the javascript version
IMHO two seems better from a quick thought, as it's faster to implement,
easier to maintain, and more flashy, but I'm fine with either solution
or even other solutions (like a @open attribute in site.xml, but would
have to think how to do it).
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Menu questions
Posted by Jeff Turner <je...@apache.org>.
On Tue, Aug 05, 2003 at 12:11:15PM +0200, Nicola Ken Barozzi wrote:
>
> Juan Jose Pablos wrote, On 05/08/2003 10.07:
> >Jeff,
> >How difficult could be to have both types of menus and a switch to
> >activate one or another?
It is a special case. Normally, you'd want child pages to appear in the
menu. In this case, we especially didn't -- the child pages were only
linked to from the page body.
> How different is this from my JS version of the collapsed menus?
Two differences:
1) index.html had no visible child pages. In JS, it would.
2) The parent entry in the menu, 'Index', loads a page when clicked. In
JS, the entry would trigger an open/close action, not load a page.
http://cvs.apache.org/~jefft/forrest/samples/hidden-menus-site/
This is a minor limitation with the JS, that menu entries cannot double
as both page links and parents of other entries. Either a menu entry is
a page link, or an open/close menu category.
--Jeff
> IIUC it can be done with that too, just by adding a parameter in
> skinfonf (@openmenus=all|none|first); try the krysalis-site skin.
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
Re: Menu questions
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Juan Jose Pablos wrote, On 05/08/2003 10.07:
> Jeff,
> How difficult could be to have both types of menus and a switch to
> activate one or another?
How different is this from my JS version of the collapsed menus?
IIUC it can be done with that too, just by adding a parameter in
skinfonf (@openmenus=all|none|first); try the krysalis-site skin.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Menu questions
Posted by Juan Jose Pablos <ch...@che-che.com>.
Jeff,
How difficult could be to have both types of menus and a switch to
activate one or another?
Cheers,
Cheche
Jeff Turner wrote:
> On Fri, Aug 01, 2003 at 06:42:37PM -0400, Brett Presnell wrote:
>
>>In message <20...@expresso.localdomain> you write:
>>
>>>How does this look:
>>>
>>>http://cvs.apache.org/~jefft/forrest/samples/hidden-menus-site/
>>>
>>>It's a modified 'forrest seed' site, where page[1-5].html pages have a
>>>customized menu, showing their page*.html peers and index.html 'parent';
>>>for example:
>>>
>>>http://cvs.apache.org/~jefft/forrest/samples/hidden-menus-site/page1.html
>>>
>>>Is this more or less what you're after?
>>
>>Yes, very much so. I'm feeling guilty that you spent your time doing
>>this, but thanks very much.
>
>
> ;) I'm trying to build up a library of useful sample modifications.
>
>
>>I think that I need to understand Forrest's menu generation better
>>anyway -- by playing around with site.xml, I'm able to make some things
>>happen that I just don't understand. Maybe this will help me get
>>started.
>
>
> The practical aspects of menu generation are described here:
>
> http://forrestbot.cocoondev.org/sites/xml-forrest/linking.html
>
> The actual mechanics of it, in the sitemap, is described at:
>
> http://forrestbot.cocoondev.org/sites/xml-forrest/sitemap-ref.html#menu_xml_generation
>
> The best way to learn the sitemap is by experimentation with a live site
> ('forrest run &'; browse http://localhost:8888; tinker with
> build/webapp/*.xmap). Each intermediate step in page production is
> visible:
>
> http://localhost:8888/index.html
> http://localhost:8888/body-index.html
> http://localhost:8888/tab-index.html
> http://localhost:8888/menu-index.html
> http://localhost:8888/book-index.html
> http://localhost:8888/menulinks-index.html
>
> There is some XSLT black magic in the menulinks pipeline (in menu.xmap),
> where site.xml is first processed.
>
> --Jeff
>
>
>>Thanks again.
>>
>>--
>>Brett Presnell
>>Department of Statistics
>>University of Florida
>>http://www.stat.ufl.edu/~presnell/
>>
>>"We don't think that the popularity of an error makes it the truth."
>> -- Richard Stallman
Re: Menu questions
Posted by Jeff Turner <je...@apache.org>.
On Fri, Aug 01, 2003 at 06:42:37PM -0400, Brett Presnell wrote:
>
> In message <20...@expresso.localdomain> you write:
> >
> > How does this look:
> >
> > http://cvs.apache.org/~jefft/forrest/samples/hidden-menus-site/
> >
> > It's a modified 'forrest seed' site, where page[1-5].html pages have a
> > customized menu, showing their page*.html peers and index.html 'parent';
> > for example:
> >
> > http://cvs.apache.org/~jefft/forrest/samples/hidden-menus-site/page1.html
> >
> > Is this more or less what you're after?
>
> Yes, very much so. I'm feeling guilty that you spent your time doing
> this, but thanks very much.
;) I'm trying to build up a library of useful sample modifications.
> I think that I need to understand Forrest's menu generation better
> anyway -- by playing around with site.xml, I'm able to make some things
> happen that I just don't understand. Maybe this will help me get
> started.
The practical aspects of menu generation are described here:
http://forrestbot.cocoondev.org/sites/xml-forrest/linking.html
The actual mechanics of it, in the sitemap, is described at:
http://forrestbot.cocoondev.org/sites/xml-forrest/sitemap-ref.html#menu_xml_generation
The best way to learn the sitemap is by experimentation with a live site
('forrest run &'; browse http://localhost:8888; tinker with
build/webapp/*.xmap). Each intermediate step in page production is
visible:
http://localhost:8888/index.html
http://localhost:8888/body-index.html
http://localhost:8888/tab-index.html
http://localhost:8888/menu-index.html
http://localhost:8888/book-index.html
http://localhost:8888/menulinks-index.html
There is some XSLT black magic in the menulinks pipeline (in menu.xmap),
where site.xml is first processed.
--Jeff
>
> Thanks again.
>
> --
> Brett Presnell
> Department of Statistics
> University of Florida
> http://www.stat.ufl.edu/~presnell/
>
> "We don't think that the popularity of an error makes it the truth."
> -- Richard Stallman
Re: Menu questions
Posted by Brett Presnell <pr...@stat.ufl.edu>.
In message <20...@expresso.localdomain> you write:
>
> How does this look:
>
> http://cvs.apache.org/~jefft/forrest/samples/hidden-menus-site/
>
> It's a modified 'forrest seed' site, where page[1-5].html pages have a
> customized menu, showing their page*.html peers and index.html 'parent';
> for example:
>
> http://cvs.apache.org/~jefft/forrest/samples/hidden-menus-site/page1.html
>
> Is this more or less what you're after?
Yes, very much so. I'm feeling guilty that you spent your time doing
this, but thanks very much. I think that I need to understand
Forrest's menu generation better anyway -- by playing around with
site.xml, I'm able to make some things happen that I just don't
understand. Maybe this will help me get started.
Thanks again.
--
Brett Presnell
Department of Statistics
University of Florida
http://www.stat.ufl.edu/~presnell/
"We don't think that the popularity of an error makes it the truth."
-- Richard Stallman