incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florian Holeczek <flor...@holeczek.de>
Subject Re: ReferenceManager rewrite: seeking a little discussion
Date Sun, 14 Mar 2010 16:40:17 GMT
Hi Andrew,

we've known this issue for quite a long time already, haven't we?
I've been trying to put the focus on it several times (search the list
for normalization, page name, wiki name). Happy to see that this is
finally recognized as a real problem before 3.0 release :-)

My opinion in short: Introducing and using UUIDs is certainly the
standard and well-proven way to solve such a problem in information
science. However, we're building a wiki server and the wiki way is using
wiki names as identifiers. My opinion was and is that we need to
normalize wiki names, which means to think about a mathematical function
(probably surjective) to map a given wiki name to one defined page.
Unfortunately, this may mean that we're breaking links by removing the
fuzzy logic we've been using up to now.

So basically, a -1 from me for the UUID solution.

Regards
 Florian


Am 14.03.2010 16:29, schrieb Andrew Jaquith:
> 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

Mime
View raw message