+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 <[email protected]>: > Sounds good. > > On Mon, Nov 10, 2014 at 1:54 PM, Marius Dumitru Florea > <[email protected]> wrote: > > On Mon, Nov 10, 2014 at 1:32 PM, Eduard Moraru <[email protected]> > 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 < > [email protected]> > >> 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 > >>> <[email protected]> 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" <[email protected]> > 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 > >>> >> [email protected] > >>> >> http://lists.xwiki.org/mailman/listinfo/devs > >>> > _______________________________________________ > >>> > devs mailing list > >>> > [email protected] > >>> > http://lists.xwiki.org/mailman/listinfo/devs > >>> > >>> > >>> > >>> -- > >>> Thomas Mortagne > >>> _______________________________________________ > >>> devs mailing list > >>> [email protected] > >>> http://lists.xwiki.org/mailman/listinfo/devs > >>> > >> _______________________________________________ > >> devs mailing list > >> [email protected] > >> http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Thomas Mortagne > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
