forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Presnell <presn...@stat.ufl.edu>
Subject Re: Menu questions
Date Tue, 19 Aug 2003 16:00:33 GMT

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 <bgol75$vpi$1@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)
> ---------------------------------------------------------------------

Mime
View raw message