All (and especially Janne) -- In digging into some of the remaining bugs clustered in PageRenamerTest, I was forced to confront what I'd coded up during the last re-write of ReferenceManager. Lots of the PageRenamerTests are still broken. The problem with page-renaming relates, I suspect, to a checkin Janne did previously that sought to handle case-sensitivity filesystem issues. To put it simply, the relationship between the wiki path (as stored in the JCRWikiPage ATTR_TITLE attribute) and the filesystem wasn't being dealt with gracefully by ReferenceManager. The bug was too complex to track down, and I didn't have the patience and time to do it.
I don't mean to blame Janne for this -- not at all. It merely sheds light on the difficulty of keeping references when the identifiers are page names. When the page name changes, we have to jump through lots of hoops to keep the references intact. You can blame ME for that. It reminded me of the old saying "programmers will create the most complex things they can debug". In thinking this through a bit more, I thought it might be better if we stored references as UUIDs. This means (for example) that renaming is simple -- all we really need to just change the page text, rather than the reference "pointers". So, that's what I've been experimenting with. It seems to work really, really well, and the code is simpler. The only odd case we have to deal with is when we're referring to a page that hasn't been created yet. In that case, what I've chosen to do is create dummy pages in a separate JCR branch (part of the /jspwiki/wiki:references node tree). Then, when pages are added in ContentManager, we check FIRST to see if that page is in the "not-created" tree. If it is, we MOVE it to the pages tree and then save as normal. Deletions work in reverse: if the page has any inbound references, we move it back to the "not created" tree to ensure that references from live pages stay intact; otherwise we zorch the page as normal. The "not created" page tree, by the way, is also an example of something I'm calling a "page foundry" -- a place where future pages are born but not yet moved into production. I can imagine other foundries -- for example, a per-user foundry for drafts. Maybe "nursery" is a better metaphor, but you get the idea. Thoughts? The code isn't quite ready, but it is progressing nicely. We might as well fix it before the 3.0 release, right? Andrew
