aCOSwt a écrit :
- Dans ce contexte, un bout de code qui ne sert à rien est strictement prohibé.
J'entendais par là un test qui devient inutile mais qui n'invalide en rien la démarche.
a écrit :
Je m'accorde volontiers au fait que l'usage de standards / best practices, sécurise significativement la phase de codage mais ce serait aussi un tort que de s'imaginer que cela dispense d'une phase de validation.
Je ne pense pas qu'on ait exprimé cela...
a écrit :
Tu as bien cerné le prix à payer : où faut-il s'inscrire quand on crée un nouveau support. C'est vrai que le code aura toujours un temps de retard par rapport aux offres de clients.
Mais ce défaut est le propre de TOUTE application client / serveur si je ne m'abuse.
En attendant, je n'enverrais pas de code erroné sur une version incompatible. Je fonctionne en tout ou rien, ce qui n'est pas la cas de ta démarche qui est susceptible de comporter de nombreuses failles à chaque amélioration du support.
a écrit :
Dans la pratique d'une réalisation collaborative sans liens de subordination entre des collaborateurs, chaque collaborateur réalise en fonction de ses moyens techniques toujours limités si l'objet de la réalisation n'est pas informatique.
La contribution de chacun est excessivement hétéroclite. Et l'intérêt de la teneur de cette contribution dépasse de beaucoup la question de savoir quelle fonction utilisée est ou non disponible sur tel ou tel navigateur.
Si de plus la somme de travail de compilation est telle qu'il est impossible de rentrer dans le code de chacun, il peut être éminement préférable de restreindre l'affichage de la page aux seuls browsers exactement identiques à celui sur lequel la contribution a été validée.
Je reconnais que c'est un peu bourrain mais... c'est à mon sens plus secure.
Non, ça l'est nettement moins. Il n'est pas seulement question des capacités de chacun; tu fais rentrer des paramètres que tu ne peux contrôler (l'évolution des supports), ce qui te donne toujours un temps de retard. Ton code peut-être deux à trois fois plus lourd étant donné que même si une méthode est "cross-browser", ce paramètre arrive après la détection du navigateur, ce qui t'oblige à générer du code supplémentaire (le truc strictement prohibé dont tu m'as parlé tout à l'heure).
Ce qui m'embête le plus, c'est qu'un débutant lisant ces lignes ne comprendra pas mot de ce que l'on dit mais sera susceptible de pencher pour cette facilité "apparente" qu'est la détection de navigateur... qui est fort "trompeuse" et qui même avec le plus grand soin apporté ne sera jamais sûre.
Quoiqu'il en soit, dans les deux cas, notre approche fonctionne ou au pire ne transmet rien. Si elle ne transmet rien, l'erreur est facilement repérable puisqu'elle n'invalide pas les méthodes qui ont lieu en amont.
La détection de navigateur, quant à elle, est située en amont, ce qui fait que soit ça fonctionne soit ça envoie une masse de code erroné à tout un support... sans compter que la recherche de l'erreur sera bien plus lourde pour ne pas dire difficile car non parlante. Rien n'indiquera que le problème vient de cette détection et il faudra une fois de plus démultiplier le code lorsque tu l'auras repéré.
Quelqu'un qui joue avec la détection de navigateur sur le net aurait, aujourd'hui, des milliers de support à prendre en charge, ce qui rend cette approche complètement farfelue. Au temps des dinosaures où deux monstres se battaient en duel pour assurer leur suprématie, c'était concevable mais cette époque est révolue depuis belle lurette...
(en fait c'est la tentative même de croire que l'on peut encore détecter le navigateur qui est vouée à l'échec mais bon ça, je crois que ça a pas été entendu/compris/pris en compte)
