10 Nov
2014
10 Nov
'14
12:32 p.m.
Of course, the other thing to do would be going the direction of helpful
suggestions:
1) When creating a resource (pages, spaces, wikis) we can propose resources
that already exist similar to the entered name. This solves both casing and
spelling issues. The point is to avoid creation of similar resources when
reusing would have been the best way to go.
2) When landing on a non-existing resource, we can suggest similar
resources instead of just showing the standard "resource not found"
message. This covers URL mistyping and outdated links.
Side Note: Perhaps we could do some sort of similar improvement to wiki
links that, when a document does not exist, directly point to edit the new
page. Instead, they could point to the wiki creation step with prefilled
form values and suggestions. Other ideas might exist here.
General example: User enters "test" and the UI suggests both "Test"
(casing) and "testing" (possible mistyping) existing resources.
This would probably be the simplest to implement without significant
performance problems. However, this would be just UI candy and the platform
would be left the way it is, a free-for-all.
Thanks,
Eduard
On Mon, Nov 10, 2014 at 1:06 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
Pretty much the same comments here.
On personal side this is one of the thing I hate about Windows ("just
do what the hell I told you to do and don't try to be clever").
On technical side everyone should understand that this is a huge
refactoring that will produce regressions for at least one year.
Another things is that it's slower so performance are going to be
worst in most of the XWiki code.
On Mon, Nov 10, 2014 at 11:24 AM, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
and
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
I'm undecided. As a technical Linux user I
prefer case sensitivity, but I
can see why this is sometimes unexpected for non-technical users. I'm not
sure how you plan to implement this. I know this thread is not about the
technical aspects but still I think it's important to consider the cost
that this change will imply.
First, even for a case insensitive system, I think it's very important to
preserve the case entered by the user. For instance, If I create a user
with the alias 'myCoolAlias' then I wouldn't like to see
'mycoolalias'
displayed in the UI. Same, if I attach a file named
'myCoolPresentation.odp' then I want to see precisely that name on the
list
of attachments. So we need to store case
sensitive values in the
database.
The difference from now will be:
* when creating an entity: check that there's no other entity that has
the
same normalized reference
(toLowerCase/toUpperCase)
* when retrieving an entity: look for normalized references
This means we'll have to call toLowerCase/toUpperCase very often so we
need
proper database indexes. Otherwise we'll have
a performance impact.
Second, we have lots of places that query the database and since we have
to
store the raw case-sensitive values then we need
to update all this
places.
Moreover, since it's not about a single
field/column I'm not sure we can
write a query filter to lower the case automatically. Then we also have a
lot of extensions that query the database and that create entities. Those
will have to be updated too.
Lastly, AFAIK lower case and upper case are locale dependent. The 'lower'
query function doesn't have a locale parameter so it depends on the
locale
the database has been configured with. So there
can be cases when a user
won't be able to retrieve an entity using some locale dependent lowercase
version of the reference because the database computes the lower case
differently than what the user expects (because it uses a different
locale).
Thanks,
Marius
On Nov 7, 2014 12:34 PM, "Eduard Moraru" <enygma2002(a)gmail.com> wrote:
>
> Hi users and devs,
>
> I would like to have your opinion on the topic of case sensitive vs case
> insensitive and which one you prefer in XWiki.
>
> Currently, XWiki is case sensitive. This means the same resource name
> (document name, space name, etc) can be written with either small
letters
> or big letters or a mix.
>
> Examples: You can have both "Main.Test" and "Main.test" as 2
different
> documents. Also, you can have "XWiki.Admin" and "XWiki.admin" as
2
> different users. This also applies to URLs, as "/Main/Test" is different
> from "/Main/test" or "/main/test", so all these 3 are different
resources.
Even from this short description, one can already identify possible
problems of this approach.
From the top 3 operating systems (Linux, Mac an Windows), only Linux is
case sensitive, the other two (more user-focused Operating Systems) are
both case insensitive.
Since XWiki has one of its main targets the Enterprise users, it is safe
to
> assume that the correct approach would be to also be more user-focused simplify
things and avoid confusions by being case insensitive as well.
Also, a quick search on existing issues validates the need for this
improvement:
http://jira.xwiki.org/issues/?jql=text%20~%20%22case%20insensitive%22
What do you think? Is it OK to keep XWiki case sensitive, or would you
prefer it case insensitive? Bring arguments.
I have also created a jira issue for this idea:
http://jira.xwiki.org/browse/XWIKI-11412 to track it in the future.
Thanks,
Eduard
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs