incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <andrew.r.jaqu...@gmail.com>
Subject Re: ReferenceManager rewrite: seeking a little discussion
Date Sun, 14 Mar 2010 17:45:16 GMT
You got it right except for the last point. If anything, it makes the
code slightly simpler in most respects -- it cuts down the amount of
code by about 10% in ReferenceManager, notably in the renaming code.

As for the broader issue you are raising, see the reply I just sent to Harry.

Andrew

On Sun, Mar 14, 2010 at 1:35 PM, Florian Holeczek <florian@holeczek.de> wrote:
> 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? ;-)
>
> Regards
>  Florian
>
> 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 <florian@holeczek.de> 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
>>>
>

Mime
View raw message