On Sat, 29 Jan 2005 19:17:49 -0500 (EST), Henri Yandell <[EMAIL PROTECTED]> wrote: > > Next on my list of renovations are the Jakarta download pages. Although > the cgi isn't hooked up, how do the following generated files look? > > http://www.apache.org/~bayard/jakarta/site/downloads/download.html
Definitely much tidier than before. I like having source and binary together - with the present setup it is a pain to download both. > In case it looks too crap (because of the missing cgi), look at: > > http://www.apache.org/~bayard/jakarta/site/binindex.html > > to see how the page normally looks when cgi is not present. > > The Commons download page is still a big list, it could also be broken > down into a separate page per component. The same could happen for > Taglibs, currently I've stayed with the link rather than having individual > Taglibs be in the download section, the aim being to change current things > as little as possible. > > There are some simple flaws that need fixing, md5/pgp's are shown even > when not available, and the mirror info, md5 info and pgp info are shown > even when they're not available. All easy to fix. Also a few missing > things like links to readme's and change-reports. Also easy enough to fix. It might be useful to be able to specify these at individual file level, as well as higher up. e.g. one could have a hash attribute, which would be hash="md5" if present, and hash="none" if not. Ideally these would default to the enclosing level. Similarly for the signatures, could use sig="PGP" > Deployment-wise, my idea would be to replace binindex and srcindex with > this download.html page. It's small enough that binindex.cgi#tomcat won't > be a problem when the #tomcat fails. But ideally, it won't fail ... > Rather than having projects linking to download.html though, they would > link directly to their particular page. So ORO would kill its current link > of binindex.cgi#oro and move to downloads/downloads_oro.html. This would mean every project updating their web-pages, which would take some while to do. Or could the cgi files be rewritten to do this automatically? If not, I think the original links need to be supported, e.g. by redirecting binindex.cgi and srcindex.cgi to downloads.html and ensuring that the original names are still present. > The pages are created by taking a downloads.xml file, turning it into > xdocs-format pages and then turning them into html pages. The interesting > stuff is in: > > http://svn.apache.org/repos/asf/jakarta/site/xdocs/downloads/ I like the simpler layout of the downloads section. Much easier to update. Though it would be nice if the directory did not have to be repeated in each link, and ditto the version information. How about something like: <group label="Binary" dir="jakarta/tomcat-5/v5.0.28/bin"> <download file="README.html" title="README (contains packaging information)"/> <download file="jakarta-tomcat-5.0.28.exe"/> <download file="jakarta-tomcat-5.0.28.tar.gz"/> ... </group> where title is an optional attribute for the link text, replacing the file name. dir could be an optional attribute for <download> tags if required - it would then override the parent attribute. > I changed my original suggestion of having a dynamic page which could be > given any filename as I want to avoid having too much in the way of > dynamic stuff running. > > It's generated with 'ant -f build-downloads.xml' in the jakarta/site/ > directory, and puts the output into tmp/site/downloads/. > > Anyway. More work to do, but I wanted to see what opinions there were > before I put anymore time into cleaning it up :) > > Opinions? > > Hen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
