forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <je...@apache.org>
Subject Re: Menu questions
Date Wed, 20 Aug 2003 11:05:17 GMT
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 <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