Dev Log - r708

Tracking reviki development

[2008-03-31] XHTML validation

So it turns out this page is horribly, horribly invalid finally 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.


  1. Attachments page invalid when no previous revisions (empty <ul>).
  2. Duplicate form input ids on attachments page.
  3. Still need to hook the validation up to the markup renderer.
  4. Fix renderer output (block elements inside p mostly).
  5. Fix new rendering glitch above (the **).
  6. Figure out why the validation is so slow.
  7. Add at least the WikiCreole page text as a more substantial functional test. The existing tests mostly test one element or the interaction between two elements.

[2008-03-30] A favicon (r650)

Sites without a favicon look dull, something the current reviki design needs no help with! I'm no graphics wizard but on the basis that something's better than nothing:


That'll do for a while. Cheers to the folks at dynamicdrive for making this easy (heh, perhaps too easy...)

Favicon maker- Create a favicon from any image

[2008-03-30] Title revision now last changed revision (r637)

The title revision is the last changed revision, rather than the accessed revision. As it was it just wasn't useful information, now you can get some idea of how old a page is. One problem common to all forms of documentation is parts inevitably get stale. It's good to have a visual indication of how recently the page has been updated. Perhaps for that reason the last changed date / user should be more visible...

[2008-03-30] Atomic commit for adding attachment and link (r629)

For a while now we've had uploading an attachment split across two commits, one creating the PageName-attachments directory (if requried) and the other committing the attachment file. As of r619 it got worse - we now automatically add a link to the attachment to the associated page.

Time to tidy SVNPageStore/BasicSVNOperations to make it easy to create the directory and the file in the same commit. This will be needed for RefactorRename too.

Update r629: The mutator methods on BasicSVNRepository now do less to give the SVNPageStore more control over combining modifications. All the operations needed to upload an attachment are now a single commit. Having to assemble all the actions up-front - because SVNRepository isn't re-entrant - leads to a clumsy separation of figuring out if something needs to be done and doing it - suspect we could pull out a prepare / perform interface. Revisit for RefactorRename.