commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject Re: [all][site] Site menu proposal
Date Mon, 08 Mar 2004 22:42:19 GMT


Dirk Verbeeck wrote:
> OK, most people want the component specific menus & the Project 
> Documentation together.
> http://cvs.apache.org/~dirkv/commons-site2/dbcp/index.html
> 
> What is left is the question if we want a list of (sandbox) components 
> in the left menu or not.
> 
> The current proposal (option 1) is to have 2 collapsed menu items in the 
> top menu.
> (a) http://cvs.apache.org/~dirkv/commons-site2/index.html
> 
> They are only expanded when you are on the componets/sanbox page.
> (b) http://cvs.apache.org/~dirkv/commons-site2/components.html
> (c) http://cvs.apache.org/~dirkv/commons-site2/sandbox.html
> 
> On the other general pages and on the component specific pages they are 
> collapsed.
> (d) http://cvs.apache.org/~dirkv/commons-site2/contributors.html
> (e) http://cvs.apache.org/~dirkv/commons-site2/dbcp/configuration.html
> 
> This has the advantage that if a new component is created only a few 
> pages have to be updated (b or c).
> The [+] is also nice because it is a visual reminder there is more to 
> find behind the item.
> 
> Option 2: same menu but do not expand the menu on pages b & c.
>
> Option 3: expand the components menu on a,b,c,d (and move to bottom)
> 
> Option 4: expand the components & sandbox menu on a,b,c,d
>           (and move to bottom)
> 
> Option 5: expand the components menu on a,b,c,d,e
>           (and move to bottom)
> 
> Option 6: expand the components & sandbox menu on a,b,c,d,e
>           (and move to bottom)
> 

> My preference is to the current one (option 1). Option 5 & 6 would 
> require a full site rebuild of all components when a new component is 
> added. Option 3 is not very fair to the sandbox components wanting more 
> visibility to grow.
> 

1.) Ideally the site will be rebuilt on a regular basis to keep 
everything uptodate (ie Once a week would be respectable for the entire 
commons) so I'm not concerned about when projects are added/removed from 
the commons as a whole.

2.) It obvious people do not want the components expanded on top of the 
project documentation, thats what got us here in the first place.

I'd vote +1 for Option 6 or +1 on Option 2.

(-1 for Options 1,3-5).

> I would put 2 tables with all components on the homepage. Implemented 
> with reusable XML entities the tables will be the same as on the 
> components & sanbox pages.

You could (should) use velocity tags in the xdoc's to iterate over the 
reactor projects and include their contents, using the entities is not 
optimal for generating a list of the projects. You have to edit the file 
when you add/remove projects. If you use the reactor, then the list is 
built off the included project.xml descriptors, this is the same for the 
navigation, the navigation.xml project list can be built the same way.

-Mark


-- 
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message