Mailing-List: contact jspwiki-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jspwiki-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of dirk.frederickx@gmail.com
 designates 209.85.200.175 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=WxhNdtLsrBMx1wALZdCl5qtA9EO+rpATUylvlXL44LAzTnxloYUeSbdrEh8euhJXTd
         NMcTIkQnK8HP6b66BVQBOcPkSNDJd30NNvjkr005hmX+grrdtNQRCt5SIrMuBifkmPJy
         +r0HPRJb+jt9/caaqGsFgP2wfhmMxpejkZUhc=
Message-ID: <15cc92000901040346v315bf482m6aa176e868e822de@mail.gmail.com>
Date: Sun, 4 Jan 2009 12:46:49 +0100
From: "Dirk Frederickx" <dirk.frederickx@gmail.com>
To: jspwiki-dev@incubator.apache.org
Subject: Re: WikiName normalization
In-Reply-To: <13EA71B9-E238-4E39-B06B-2E78FE3A9709@ecyrd.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_103318_29299394.1231069610051"
References: <97777F4E-37EA-47A2-9984-87B935594914@ecyrd.com>
	 <647021932.20090103235048@holeczek.de>
	 <13EA71B9-E238-4E39-B06B-2E78FE3A9709@ecyrd.com>

------=_Part_103318_29299394.1231069610051
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

May be it would be useful to have a plugin which would list pages with
similar names.

This info could be added to the left-menu, info-tab or quick-navigation
dropdown to help a user to find *that other page he is looking for*

This [{IndexSimilarPages }] could look for pages with
- different white-spaces
- with different upper/lower case.
- singular/plural page-names


dirk


On Sun, Jan 4, 2009 at 12:02 PM, Janne Jalkanen <Janne.Jalkanen@ecyrd.com>wrote:

> I think clear rules are still missing on how an arbitrary link is
>> translated into a WikiName. These should really be tight rules like
>> you already wrote about MediaWiki:
>>
>
> Hm?  I thought I wrote the rules out already... What is missing, to be
> exact?
>
>  Regarding backwards compatibility, I'd recommend ignoring old special
>> cases (where existing) in favor of allowing for simple rules for 3.0+.
>>
>
> I thought that's what I said in the proposal :)
>
> The only thing really to wonder about is the english plurals -setting.
>  There's some annoying magic in ReferenceManager to make sure that
> "TestPage" and "TestPages" are considered same objects.
>
>  Especially the hidden platform dependencies, which are obviously
>> existing in the file-based provider up to 2.8 should be eliminated.
>>
>
> These are more or less errors, not really features.
>
>  * The simple way: Implement some fallback rules in wiki page lookup in
>>  order not to break existing links. If feasible, the corresponding code
>>  should be marked as being for this purpose only.
>>  Problem: What if some old link isn't valid any more and therefore
>>  gets permanently redirected by this code? Then, someone creates a
>>  new page whose name is just this old link's name. This would break
>>  the old link without touching it directly.
>>
>
> Could you elaborate on that?  The current recommendation to create links
> (2.8) is to simply put them inside brackets.  For example, [This is a page]
> creates a link to a wikipage called "This is a page".  In 2.4 and
> previously, this would actually create a link to "ThisIsAPage".
>
> Our current implementation checks first for the existence of "This is a
> page", and then for backwards compatibility reasons, "ThisIsAPage".
>  However, internally, these pages are not considered the same, so it is
> possible to create "This is a page" even when "ThisIsAPage" exists, and the
> new page will then take precedence.
>
> Because *most* of the links at jspwiki.org are these backwards compatible
> forms, I don't think we can throw it away.  However, what we can do is to
> make it a configuration item.
>
>  * If the simple way isn't feasible, implement a migration tool which
>>  converts the page names and links in existing repositories.
>>
>
> That may be really difficult to do (he said, having just watched one
> corporate migration where things were renamed automatically).  Besides,
> since it modifies the repository, it needs some pretty heavy-duty testing.
>
> The export tool can output the names in normalized form, but I'd hesitate
> to change the repo contents itself.  Besides, it wouldn't work on most
> plugins, etc.
>
> /Janne
>

------=_Part_103318_29299394.1231069610051--