==Tracking reviki development ====[2008-05-05] Atom feed improvements and URL change (r828) For consistency with the alternate format for search the atom feed is now at {{{RecentChanges?ctype=atom}}}. I hope to introduce the ability to view more of the wiki as atom feeds and entries over time. I've also added '?revision=NNNN' to the atom:id of the entries. It seems that bloglines (and probably others) gets really confused by multiple entries with the same id (though the specification permits this). I've also started to write [[http://svn.dsl.local/svn/reviki/trunk/src/org/reviki/wiki/feeds/XPathAccess.java|code]] to make it bearable to write tests against XML output in XPath. Seems like something that could be generally useful, might be worth tidying up and pulling out of reviki. ====[2008-05-05] ConfigCss regression fixed (r823) In r785 ConfigCss was ignored - the default styling always used. I found a better home for the code that set the default CSS URL (now in the view) but failed to notice I'd moved it after the code setting the wiki specific CSS URL. The default now takes care not to overwrite anything previously set and I've added some tests. Perhaps I should brighten up reviki.org to make doubly sure but CSS just isn't my thing. **Update:** I've made the page titles (slightly) more colourful. ====[2008-05-05] HtmlUnit functional tests now run in ant (r814) It will download tomcat, built and deploy a war, start tomcat, wait for it to come up, run the tests against it and clean up. Magic. I was particularly impressed with {{{ }}} ...I was expecting to have to do something horrible like take a guess and sleep. Unfortunately some manual setup of the test wiki is still required (documented in the [[trunk:build.xml|ant file]]). If we supported file repositories perhaps ant could do this too. Another possible enhancement is XSLT or similar to munge the tomcat port to something less likely to clash. ====[2008-04-28] Configurable base URL (r789) As noted on ConfigFile you can now set a property that determines the base URL for the wiki. Now when the reviki tomcat instance is behind something like Apache there is much more freedom as to what the URL space looks like. You can easily have http://www.example.com/wiki/FrontPage and http://microsite.example.com/team/FrontPage both being served from the same tomcat. If you don't set the base URL it will continue to be based on the request and the '/pages/wikiName/PageName' structure. **Update (r807)**: Missed the resource URL for the search suggest feature's CSS. That's fixed in r807. ====[2008-04-20] Atom feed fixes (r755) The atom feed [[http://feedvalidator.org/check.cgi?url=http%3A%2F%2Freviki.org%2Fpages%2Freviki%2FRecentChanges%2Fatom.xml|is now valid]]. Issues were: * Missing author element * Missing id element (now set to URI of feed) * Date format issues The validator now gives warnings about update times (due to a move, so expected) and multiple entries with the same id (which are valid as they are changes to the same page). ====[2008-04-20] XHTML validator now works properly and is in SVN The (trivial) XHTML validator - XHTMLValidate - is now somewhat packaged up and is in SVN. I switched from using a catalog resolver to using a custom entity resolver as it still seemed to be going to the web when access was available, explaining why the tests were sometimes very slow. ====[2008-04-17] NightlyBuilds now available Erm that's it really. http://downloads.reviki.org/nightly/ ====[2008-04-15] ConfigAutoProperties I'm working on addressing one of the attachment related stories for the 1.0 release. The plan is to add ConfigAutoProperties which will be a text page containing the contents of the [auto-props] section of the svn config file. These will be used for new attachments. This ought to make browsing the SVN repository directly more pleasing. The common practical problem is that the PDF files are incorrectly added as to SVN as text (as they often are for the first few bytes until you hit a compressed stream). I'll also address using these mime types at attachment download time too (I think we currently always set application/octet-stream). **Update (r720):** We now have ConfigAutoProperties with some default content to be documented on AboutConfigAutoProperties. Decided there's no point setting mime-type on download because the current behaviour results in the browser / OS mime-type mappings being used which is probably more comprehensive. Will gladly revisit if anyone has a use case. ====[2008-03-31] XHTML validation So it turns out this page is --horribly, horribly invalid-- finally [[http://validator.w3.org/check?uri=http%3A%2F%2Freviki.org%2Fpages%2Freviki%2FDevLog&charset=%28detect+automatically%29&doctype=Inline&group=0|valid]] as of r682. Time to find a validator I can hook into the HtmlUnit functional tests and the unit tests for the renderer. **Update (r660)**: * We have XHTML DTD validation hooked into the functional tests. Surprisingly slow though, even with catalog remappings for the W3C DTDs. * This page is valid except for an issue with ul elements generated by the renderer. **Update (r675)**: * Search result highlighting is now valid XHTML. * Diffs now valid XHTML. Remaining: # --Attachments page invalid when no previous revisions (empty {{{