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
