7 Nov
2014
7 Nov
'14
11:33 a.m.
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 and
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
7 Nov
7 Nov
12:03 p.m.
Hi Edy,
thanks for your message. From a forward-looking standpoint, I 100% agree
with you that switching XWiki to case-insensitive would be a good thing to
do. I've seen others (as well as myself) be lost because they were going to
.../xwiki/bin/view/Main/Xyy instead of .../xwiki/bin/view/Main/XYY and
vice-versa. If we were to make the decision today, I can't see a good
reason why not to go case-insensitive, especially when targeting business
users.
However we're not starting from a blank slate. There might be (I don't know
that there is, but there might be) legitimate use cases for a page named
"Xyy" vs a page named "XYY", both in the same wiki. I'd like to
have a
better idea of the consequences of this change, as well an analysis of a
public site such as xwiki.org to see whether this could be causing
unforeseen and other unexpected issues. In other words: what could go wrong?
Thanks,
Guillaume
ᐧ
On Fri, Nov 7, 2014 at 11:33 AM, 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 and
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
2:45 p.m.
New subject: [xwiki-devs] [xwiki-users] [Discussion] Make XWiki Case Insensitive. WDYT?
As far as I know, Mac can be either case sensitive or case insensitive (just
need to choose how you format your disk)*.
So we could do the same on XWiki and propose to choose between case sensitive
and case insensitive at the installation (a variable in xwiki.properties)? I'm
not against a case insentivity by default if I can switch it later.
* I have a Mac at home and mine is case sensitive but I configured it 2 years
ago. I don't know if, in the last 2 years, Apple decided to remove this choice
between case sentivity and case insensitivity.
On Fri, Nov 07, 2014 at 12:03:14PM +0100, Guillaume Lerouge wrote:
Hi Edy,
thanks for your message. From a forward-looking standpoint, I 100% agree
with you that switching XWiki to case-insensitive would be a good thing to
do. I've seen others (as well as myself) be lost because they were going to
.../xwiki/bin/view/Main/Xyy instead of .../xwiki/bin/view/Main/XYY and
vice-versa. If we were to make the decision today, I can't see a good
reason why not to go case-insensitive, especially when targeting business
users.
However we're not starting from a blank slate. There might be (I don't know
that there is, but there might be) legitimate use cases for a page named
"Xyy" vs a page named "XYY", both in the same wiki. I'd like to
have a
better idea of the consequences of this change, as well an analysis of a
public site such as xwiki.org to see whether this could be causing
unforeseen and other unexpected issues. In other words: what could go wrong?
Thanks,
Guillaume
ᐧ
On Fri, Nov 7, 2014 at 11:33 AM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
--
Jean Simard
jean.simard(a)xwiki.com
Research engineer at XWiki SAS
http://www.xwiki.com
Committer on the XWiki.org project
http://www.xwiki.org
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 and
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
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
3:58 p.m.
New subject: [xwiki-devs] [xwiki-users] [Discussion] Make XWiki Case Insensitive. WDYT?
Hi,
On Fri, Nov 7, 2014 at 3:45 PM, Jean SIMARD <jean.simard(a)xwiki.com> wrote:
As far as I know, Mac can be either case sensitive or
case insensitive
(just
need to choose how you format your disk)*.
So we could do the same on XWiki and propose to choose between case
sensitive
and case insensitive at the installation (a variable in
xwiki.properties)? I'm
not against a case insentivity by default if I can switch it later.
Yes, indeed, but I would not call that "configurable", since it involves
formatting your drive and choosing a filesystem that supports case
sensitive/insensitive names.
* I have a Mac at home and mine is case sensitive but I configured it 2
years
ago. I don't know if, in the last 2 years, Apple decided to remove this
choice
between case sentivity and case insensitivity.
At least for recent Mac computers, they come with a case insensitive FS by
default. This options is also recommended in their documentation, for
example when erasing and reinstalling your OSX:
http://support.apple.com/kb/PH18869 (Yosemite) or
http://support.apple.com/kb/PH14243 (Mavericks), etc.
Thanks,
Eduard
On Fri, Nov 07, 2014 at 12:03:14PM +0100, Guillaume Lerouge wrote:
--
Jean Simard
jean.simard(a)xwiki.com
Research engineer at XWiki SAS
http://www.xwiki.com
Committer on the XWiki.org project
http://www.xwiki.org
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Hi Edy,
thanks for your message. From a forward-looking standpoint, I 100% agree
with you that switching XWiki to case-insensitive would be a good thing
to
do. I've seen others (as well as myself) be
lost because they were going
to
.../xwiki/bin/view/Main/Xyy instead of
.../xwiki/bin/view/Main/XYY and
vice-versa. If we were to make the decision today, I can't see a good
reason why not to go case-insensitive, especially when targeting business
users.
However we're not starting from a blank slate. There might be (I don't
know
that there is, but there might be) legitimate use
cases for a page named
"Xyy" vs a page named "XYY", both in the same wiki. I'd like to
have a
better idea of the consequences of this change, as well an analysis of a
public site such as xwiki.org to see whether this could be causing
unforeseen and other unexpected issues. In other words: what could go
wrong?
Thanks,
Guillaume
ᐧ
On Fri, Nov 7, 2014 at 11:33 AM, 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
and
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
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
3:49 p.m.
New subject: [xwiki-devs] [xwiki-users] [Discussion] Make XWiki Case Insensitive. WDYT?
Hi Guillaume,
Here's a quick snippet for detecting such cases in your current wiki:
http://extensions.xwiki.org/xwiki/bin/view/Extension/Case+insensitive+docum…
Use it to detect collisions/mistakes and to have a better understanding of
the problem. It is also useful to better understand the impact, if any, on
your wiki if we were to move to case insensitive only (i.e. see how many
pages would present problems and would have to be fixed, either manually or
automatically).
Thanks,
Eduard
On Fri, Nov 7, 2014 at 1:03 PM, Guillaume Lerouge <guillaume(a)xwiki.com>
wrote:
Hi Edy,
thanks for your message. From a forward-looking standpoint, I 100% agree
with you that switching XWiki to case-insensitive would be a good thing to
do. I've seen others (as well as myself) be lost because they were going to
.../xwiki/bin/view/Main/Xyy instead of .../xwiki/bin/view/Main/XYY and
vice-versa. If we were to make the decision today, I can't see a good
reason why not to go case-insensitive, especially when targeting business
users.
However we're not starting from a blank slate. There might be (I don't know
that there is, but there might be) legitimate use cases for a page named
"Xyy" vs a page named "XYY", both in the same wiki. I'd like to
have a
better idea of the consequences of this change, as well an analysis of a
public site such as xwiki.org to see whether this could be causing
unforeseen and other unexpected issues. In other words: what could go
wrong?
Thanks,
Guillaume
ᐧ
On Fri, Nov 7, 2014 at 11:33 AM, 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
and
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
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
10 Nov
10 Nov
11:24 a.m.
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 and
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
12:03 p.m.
Hi Marius,
On Mon, Nov 10, 2014 at 12:24 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
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.
Right. I posted a similar comment on the Jira issue.
Another interesting idea I was just thinking about would be to add
uniqueness constraints in the database on lower(doc.fullName) for instance.
That would cover the creation step.
Regarding performance, I have found in some quick searches that uniqueness
constraints are also achievable through unique function-based indexes [1].
On both cases, we would have to investigate on the database support or
solutions for using a function like lower() for the database unique
constraint or the unique index.
----------
[1]
http://stackoverflow.com/questions/3944840/create-unqiue-case-insensitive-c…
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.
Not sure a filter would be the solution, since queries should be
application-specific.
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).
Well, as long as we do something like lower(myValue) = lower(dbValue)
instead of myValue = lower(dbValue), we should be good, right? (i. e. apply
the same databse collation/logic on both the searched value and the db
value so that we never get a missmatch).
Thanks,
Eduard
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
and
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
12:12 p.m.
On Mon, Nov 10, 2014 at 12:03 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
Hi Marius,
On Mon, Nov 10, 2014 at 12:24 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
Not really, the problem you will have is that lower is not going to do
it's job because you are not in the right locale. That means that you
might end up with the request thinking that two values are not equals
while if lower did its job properly it would have been. In XWiki side
we will apply the locale to String.toLower and we will get a different
result which means that you have cases where in the require two
document name are not equals but they are when you compare two
DocumentReference which might create many issues.
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.
Right. I posted a similar comment on the Jira issue.
Another interesting idea I was just thinking about would be to add
uniqueness constraints in the database on lower(doc.fullName) for instance.
That would cover the creation step.
Regarding performance, I have found in some quick searches that uniqueness
constraints are also achievable through unique function-based indexes [1].
On both cases, we would have to investigate on the database support or
solutions for using a function like lower() for the database unique
constraint or the unique index.
----------
[1]
http://stackoverflow.com/questions/3944840/create-unqiue-case-insensitive-c…
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.
Not sure a filter would be the solution, since queries should be
application-specific.
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).
Well, as long as we do something like lower(myValue) = lower(dbValue)
instead of myValue = lower(dbValue), we should be good, right? (i. e. apply
the same databse collation/logic on both the searched value and the db
value so that we never get a missmatch).
Thanks,
Eduard
--
Thomas Mortagne
Thanks,
Marius
On Nov 7, 2014 12:34 PM, "Eduard Moraru" <enygma2002(a)gmail.com> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
and
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
12:13 p.m.
On Mon, Nov 10, 2014 at 12:12 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
--
Thomas Mortagne
On Mon, Nov 10, 2014 at 12:03 PM, Eduard Moraru
<enygma2002(a)gmail.com> wrote:
s/require/request/
Hi Marius,
On Mon, Nov 10, 2014 at 12:24 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
Not really, the problem you will have is that lower is not going to do
it's job because you are not in the right locale. That means that you
might end up with the request thinking that two values are not equals
while if lower did its job properly it would have been. In XWiki side
we will apply the locale to String.toLower and we will get a different
result which means that you have cases where in the require two
document name are not equals but they are when you compare two
DocumentReference which might create many issues. 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.
Right. I posted a similar comment on the Jira issue.
Another interesting idea I was just thinking about would be to add
uniqueness constraints in the database on lower(doc.fullName) for instance.
That would cover the creation step.
Regarding performance, I have found in some quick searches that uniqueness
constraints are also achievable through unique function-based indexes [1].
On both cases, we would have to investigate on the database support or
solutions for using a function like lower() for the database unique
constraint or the unique index.
----------
[1]
http://stackoverflow.com/questions/3944840/create-unqiue-case-insensitive-c…
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.
Not sure a filter would be the solution, since queries should be
application-specific.
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).
Well, as long as we do something like lower(myValue) = lower(dbValue)
instead of myValue = lower(dbValue), we should be good, right? (i. e. apply
the same databse collation/logic on both the searched value and the db
value so that we never get a missmatch).
Thanks,
Eduard
--
Thomas Mortagne
Thanks,
Marius
On Nov 7, 2014 12:34 PM, "Eduard Moraru" <enygma2002(a)gmail.com> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
and
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
12:06 p.m.
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:
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:
--
Thomas Mortagne
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 and
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
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
1:54 p.m.
On Mon, Nov 10, 2014 at 1:32 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
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.
Big +1 for these. Something like:
* Create page "test" -> "There is already a page named 'Test'.
Are you
sure you wan to create a new page?"
* Go to /Space/test -> "Did you mean 'Test'?" / "Are you looking
for 'Test'?"
General example: User enters "test" and the UI suggests both "Test"
(casing) and "testing" (possible mistyping) existing resources.
We can use Solr.
Thanks,
Marius
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
_______________________________________________
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
2 p.m.
Sounds good.
On Mon, Nov 10, 2014 at 1:54 PM, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
On Mon, Nov 10, 2014 at 1:32 PM, Eduard Moraru
<enygma2002(a)gmail.com> wrote:
--
Thomas Mortagne
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.
Big +1 for these. Something like:
* Create page "test" -> "There is already a page named 'Test'.
Are you
sure you wan to create a new page?"
* Go to /Space/test -> "Did you mean 'Test'?" / "Are you
looking for 'Test'?"
General example: User enters "test" and the UI suggests both "Test"
(casing) and "testing" (possible mistyping) existing resources.
We can use Solr.
Thanks,
Marius
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:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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:
_______________________________________________
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
and
> 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
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12 Nov
12 Nov
5:04 p.m.
+1 with the idea of having a suggest UI instead of a hard constraint on the
platform level.
2014-11-10 14:00 GMT+01:00 Thomas Mortagne <thomas.mortagne(a)xwiki.com>om>:
Sounds good.
On Mon, Nov 10, 2014 at 1:54 PM, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
'Test'?"
platform
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
On Mon, Nov 10, 2014 at 1:32 PM, Eduard Moraru
<enygma2002(a)gmail.com>
wrote:
> 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.
Big +1 for these. Something like:
* Create page "test" -> "There is already a page named 'Test'.
Are you
sure you wan to create a new page?"
* Go to /Space/test -> "Did you mean 'Test'?" / "Are you
looking for
General example: User enters "test" and the UI suggests both "Test"
(casing) and "testing" (possible mistyping) existing resources.
We can use Solr.
Thanks,
Marius
>
> This would probably be the simplest to implement without significant
> performance problems. However, this would be just UI candy and the > 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:
>> > 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
>> and
>> >> 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
--
Thomas Mortagne
_______________________________________________
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
10 Nov
10 Nov
12:46 p.m.
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").
I agree with that, but on the practical aspects, how often do you need to
have in the same folder all the following files:
- "test
- "TEST"
- "Test"
?
Also, as Marius pointed out, the FAT/Windows filesystem is case sensitive,
it just has an uniqueness constraint, so you can name stuff however you
want to, just don`t have duplicates because you will quickly make a mess of
yourself.
It's easy to use the above argument for various cases, however IMO our goal
should be to write useful software, and the features we are discussing here
are mainly targeting the users, not the admins. My logic tells me that
users are more interested in resources and not in resource names. ("potato,
patato" [1] - see the OP on same resource, multiple names because of
casing).
Thanks,
Eduard
----------
[1] https://www.youtube.com/watch?v=Mc3Fn7R9mkE
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
1:18 p.m.
On Mon, Nov 10, 2014 at 12:46 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
On Mon, Nov 10, 2014 at 1:06 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>
wrote:
It's not so much about common use case that the fact that having two
files with different cases do exist (because pretty much everything
that is not system dependent is case sensitive) but in Windows I won't
be able to just download them without having to think about it and if
they are in a zip, just unzip it won't work, if there is such files in
a git repository I won't be able to clone or update it on Windows,
etc. Also because Windows is so clever you simply can't change your
file's case, you have to rename your file to something that does not
match and then rename it to what you really want. On the other hand
having two files with different cases in a folder never was an issue
in any way for me on Linux.
In other words being sure that I can copy/download/import anything
anywhere without having to worry about path size, support characters,
getting conflict that never really existed, etc... is of more interest
to me than being totally lost (it's so complex to understand, right)
because I have two files with different case in a folder.
I don't really see how stating that I'm not annoyed by the right
things and saying that Windows is actually great with the use case I'm
not having is going to help the debate. I already said that I have a
technical point of view and having matching between two files of
different case can be of some interest for basic users.
In the use case of XWiki what I don't like is similar to what I
explained for Windows which is that I don't like too much changing the
whole platform to make impossible to support something that might be a
real use case for any reason, impossible to import a XAR with two
pages having different case, impossible to attach files with different
case because you need it to be that way because you are using a tool
that needs it that way, etc... Basically I don't like adding a
limitation that is far from being a universal limitation.
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").
I agree with that, but on the practical aspects, how often do you need to
have in the same folder all the following files:
- "test
- "TEST"
- "Test"
?
Also, as Marius pointed out, the FAT/Windows filesystem is case sensitive,
it just has an uniqueness constraint, so you can name stuff however you
want to, just don`t have duplicates because you will quickly make a mess of
yourself.
It's easy to use the above argument for various cases, however IMO our goal
should be to write useful software, and the features we are discussing here
are mainly targeting the users, not the admins. My logic tells me that
users are more interested in resources and not in resource names. ("potato,
patato" [1] - see the OP on same resource, multiple names because of
casing).
Thanks,
Eduard
----------
[1] https://www.youtube.com/watch?v=Mc3Fn7R9mkE
--
Thomas Mortagne
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
_______________________________________________
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
1:39 p.m.
On Mon, Nov 10, 2014 at 2:18 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On Mon, Nov 10, 2014 at 12:46 PM, Eduard Moraru
<enygma2002(a)gmail.com>
wrote:
Well, yes. In Windows you will always have frustrations when making it work
with other systems that don`t have uniqueness constraints, so it`s obvious
you will have problems.
In XWiki`s case, at some point you should not have a XAR with 2 documents
with different casing in the same space, except if dealing with older
versions. (migrations from other wiki systems is another case when you
might hit this). For attachments I was not proposing an uniqueness
constraint since the collision chance is higher (files coming from
different folders on the user's HDD end up in the same space, so
c:\test.txt and d:\Test.txt both end up in Main.SomeDocument => collision).
Also, it's easy to spot a collision on an attachment since you see the list
of attachments you have uploaded. When creating a document, your focus is
narrowed and you don`t really see documents "around you".
Anyway, your points are valid and I agree that we should probably just
avoid all the confusion caused by this costly transition.
I guess the UI suggestion improvements is the only thing we are left with
at the moment.
Sure, we could try adding uniqueness constraints just at an UI level, which
could also be configurable, while the platform would remain free to do
whatever it wishes, just as long as the UI is always aware that duplicates,
even if not allowed to, could still exist. Of course, being an UI thing, it
would not be guaranteed, even if enabled, since each application could do
whatever it wishes in its UI or its components; so more of a "hit or miss"
if anyone tries to enable it.
Thanks,
Eduard
On Mon, Nov 10, 2014 at 1:06 PM, Thomas Mortagne
<
thomas.mortagne(a)xwiki.com>
wrote:
sensitive,
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").
I agree with that, but on the practical aspects, how often do you need to
have in the same folder all the following files:
- "test
- "TEST"
- "Test"
?
Also, as Marius pointed out, the FAT/Windows filesystem is case it just has an uniqueness constraint, so you can
name stuff however you
want to, just don`t have duplicates because you will quickly make a mess
of
yourself.
It's easy to use the above argument for various cases, however IMO our
goal
should be to write useful software, and the
features we are discussing
here
are mainly targeting the users, not the admins.
My logic tells me that
users are more interested in resources and not in resource names.
("potato,
patato" [1] - see the OP on same resource,
multiple names because of
casing).
It's not so much about common use case that the fact that having two
files with different cases do exist (because pretty much everything
that is not system dependent is case sensitive) but in Windows I won't
be able to just download them without having to think about it and if
they are in a zip, just unzip it won't work, if there is such files in
a git repository I won't be able to clone or update it on Windows,
etc. Also because Windows is so clever you simply can't change your
file's case, you have to rename your file to something that does not
match and then rename it to what you really want. On the other hand
having two files with different cases in a folder never was an issue
in any way for me on Linux.
In other words being sure that I can copy/download/import anything
anywhere without having to worry about path size, support characters,
getting conflict that never really existed, etc... is of more interest
to me than being totally lost (it's so complex to understand, right)
because I have two files with different case in a folder.
I don't really see how stating that I'm not annoyed by the right
things and saying that Windows is actually great with the use case I'm
not having is going to help the debate. I already said that I have a
technical point of view and having matching between two files of
different case can be of some interest for basic users.
In the use case of XWiki what I don't like is similar to what I
explained for Windows which is that I don't like too much changing the
whole platform to make impossible to support something that might be a
real use case for any reason, impossible to import a XAR with two
pages having different case, impossible to attach files with different
case because you need it to be that way because you are using a tool
that needs it that way, etc... Basically I don't like adding a
limitation that is far from being a universal limitation.
Thanks,
Eduard
----------
[1] https://www.youtube.com/watch?v=Mc3Fn7R9mkE
>
> 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:
> > 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
> and
> >> 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
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3649
days inactive
3654
days old
16 comments
6 participants
participants (6)
-
Eduard Moraru -
Guillaume "Louis-Marie" Delhumeau -
Guillaume Lerouge -
Jean SIMARD -
Marius Dumitru Florea -
Thomas Mortagne