incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florian Holeczek <>
Subject Re: ReferenceManager rewrite: seeking a little discussion
Date Sun, 14 Mar 2010 17:35:04 GMT
Hi Andrew,

thanks for the clarification! Indeed, I have misunderstood you. I must
confess that I don't know the code well enough to judge which impacts
your particular change may have. That said, I change my -1 to a 0.

But if I understand you correctly this time, the whole thing now sounds
to me as follows:
* your change is no solution to the problem I meant (a pity! ;-) )
* I think the problems you're addressing with it have their root cause
in the problem I mean
* So this would basically be a hack which makes the code more
complicated in order to fix some unit tests? ;-)


Am 14.03.2010 17:50, schrieb Andrew Jaquith:
> Hi Florian --
> Thanks for your message. Why the -1? Trying to understand the nature
> of your objection.
> I should have clarified something in my previous message. The UUIDs
> are only used by ReferenceManager -- they are not exposed in the UI at
> all, and the public methods in ReferenceManager (e.g., getReferredBy)
> still return WikiPaths like they always have. Users won't see anything
> different, and they can still enter wiki names as they always have.
> Behind the scenes, the UUIDs are stored in the back-end JCR pages as
> wiki:referenceTo and wiki:refererredBy properties. Whenever the page
> is saved, we extract out the page names that are referenced (as we
> normally do), normalize the page name, figure out the UUIDs, and then
> stash the UUIDs.
> So, in case it wasn't clear -- this UUID stuff is all under the covers.
> Does that make you reconsider your -1? ;)
> Andrew
> On Sun, Mar 14, 2010 at 12:40 PM, Florian Holeczek <> wrote:
>> 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

View raw message