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:23:58 GMT
Harry, thanks. You captured the spirit of what I'm trying to do much
more simply than I did in my previous e-mail. :)

I did NOT suggest the more radical step of replacing the actual wiki
page markup with UUIDs "under the covers" (and then de-referencing
them for viewing and editing purposes). That's a discussion for
another time. That WOULD address Florian's larger issue, combined with
a consolidation of where and how we canonicalize and resolve page
names. That, too, is a discussion for another time. :)

Andrew

On Sun, Mar 14, 2010 at 12:56 PM, Harry Metske <harry.metske@gmail.com> wrote:
> Although I cannot completely oversee the consequences of this switch, I in
> general like the idea of using internal numbers/names/labels (uuids in our
> case) instead of external (visible) names for referencing purposes.
> The issue is very similar to SQL tables, where it is much more convenient
> using identity columns as unique keys instead of "name columns" , especially
> when using foreign keys.
>
> I think this issue does not directly relate to external page names (as
> Florian discussed).
>
> With the assumption that using UUIDs is only used internally, and not
> showing up anywhere in the public API:
> +1 from me, at least something to "commit and try"
>
>
> regards,
> Harry
>
> 2010/3/14 Andrew Jaquith <andrew.r.jaquith@gmail.com>
>
>> 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