Backbone: Sensibilité à la casse du routage

Utilisez une expression régulière pour votre route et le drapeau i (insensible à la casse). Ex. : /regex/i

var Router = Backbone.Router.extend({
    routes: {
        /regex/i: "home"
    }
    ....
});

Vous pouvez ajouter manuellement des routes regex insensibles à la casse dans #initialize .

Je comprends que la spécification des URL spécifie la sensibilité à la casse, mais le fait que votre solution nécessite un bon écart par rapport à la manière normale dont les routes sont spécifiées peut causer beaucoup de maux de tête. Il existe d'innombrables logiciels Web qui ont dévié des spécifications officielles, car il s'est avéré que les spécifications officielles ne tenaient pas compte de certains cas d'utilisation importants. Je ne vous suggère pas de vous écarter de la spécification dans votre comportement par défaut, mais de ne pas offrir l'option de désactiver la sensibilité à la casse car "c'est la spécification" ignore toute la demande réelle et réelle pour ce comportement. Nous exécutons .NET sur IIS, dont aucun n'exige des URL sensibles à la casse, ce qui oblige tous nos développeurs à revenir en arrière et à corriger les milliers d'URL dispersées dans le projet juste pour satisfaire la spécification ne va tout simplement pas arriver. Il y a des questions de débordement de pile à ce sujet, des personnes qui publient des hacks et des solutions de contournement en ligne, tout cela parce que vous accordez la priorité aux spécifications du W3C par rapport aux utilisateurs réels et réels.

Si vous n'autorisez pas cela en option, exposez au moins le code associé dans le backbone (qui est actuellement dans une fermeture) afin que nous puissions remplacer ce comportement sans modifier la source d'origine.

En fait, la spécification ne dit pas vraiment que les URL sont sensibles à la casse :

"Les URL _en général_ sont sensibles à la casse (à l'exception des noms de machine). Il peut y avoir des URL, ou des parties d'URL, où la casse n'a pas d'importance , mais les identifier peut ne pas être facile. Les utilisateurs doivent toujours considérer que les URL sont cas -sensible. /u"

"En général" != "doit être." Il indique que les utilisateurs doivent toujours les considérer comme sensibles à la casse, mais c'est parce que s'ils ne le font pas, ils peuvent ne pas correctement si le routeur/serveur est configuré pour la sensibilité à la casse.

J'ai l'impression que si apache peut être configuré pour l'insensibilité à la casse, Backbone devrait être de la même manière.

Cette solution n'aide pas non plus dans les cas où la racine du routeur contient l'erreur de cas.

Par exemple, si l'application ne se trouve pas à la racine d'un domaine, comme dans le cas de www.example.com/MyApp , votre solution regex ne vous aidera pas lorsqu'un utilisateur tape www.example.com/myapp .