Pourquoi développer pour FireFox ?

[shiftcode]

Zut, celà fait la deuxième fois que j'oublie de m'authentifier ... Bon c'est pas si grave.

Mais retour d'experience c'est ce forum même.

Voilà une excellente raison de butnier sur le forum et de proposer ma pierre à l'édifice. J'y cours de ce pas.

[jv2759]

Par contre, nous avons une application web développée et maintenue par une société extérieure qui ne fonctionne que sous IE et pour lequel aucune mise en confirmité n'est prévue. L'application est plutôt bien codée, mais ils ont fait un usage intensif du document.all d'ie. Nos spécifiques (développés par mes soins) font un usage intensif du getElementById

Si vous ne pouvais rien changer avec cette société... Par contre cela montre le coter imperatif lors de future cachier des charge d'exiger la conformiter au standard, non comme un plus mais comme un prérequi.

Imagine que demain une tres gros faille de securiter dans ie, cette derniére est largement exploiter, microsoft tard à sortir un patch et n'en sort qu'un pour la sp2... Vous ête prisonier, puisque vous ne pouvais changer de naviguateur... Les seul chose qu'il vous reste à faire c'est acheter pour tout vos poste windows xp avec la sp2 (pour ceux qui n'en on pas.), acheter de nouvelle machine pour celle qui sont trop faible. Ou alors réécrire l'application entiérement...

Voilà une excellente raison de butnier sur le forum et de proposer ma pierre à l'édifice. J'y cours de ce pas.

C'est une tres bonne méthode, car elle te permetra d'avoir une idée précise de ce qui ne peux pas marchais. Voir que ben souvant le fosser entre un code bien fait et un mal fait, n'est pas si grand que cela est s'il faut passer un tout petit peux de temps pour s'adapter c'est beaucoup plus facile qu'on ne le pense...

PS : si vous avais utiliser css et des getElementById, il y as de forte chance que s'il reste des probléme ces dernier sois mineur.

[shiftcode]

Bien souvent les développeurs du monde libre font l'erreur de croire que :
- Les applications web que nous développons et utilisons sont utilisées par des gens extérieurs à la société;
- Nous n'avons pas protégé notre réseau par un firewall. Le notre bloque toutes les transactions entrantes vers nos serveurs internes;
- Nous achetons des prestations de développement.

Or, dans le cas présent :

Par contre cela montre le coter imperatif lors de future cachier des charge d'exiger la conformiter au standard

Nous avons acheté une application déjà conçue et déployée chez d'autres clients, sur laquelle nous avons eu des journées de consulting pour paramétrer l'application en fonction de nos besoins et un contrat de maintenance.

Imagine que demain une tres gros faille de securiter dans ie

L'application en question est exclusivement utilisée en interne par des ordinateurs dont la mise à jour anti virale se fait au moins une fois par jour sur l'ensemble des machines connectées sur notre réseau. L'antivirus en question sait repérer les exploits de ce genre et les stopper (cas déjà vécu il y a quelques jours avec SOBER.I)

Ces quelques mises au point étaient nécessaires, et penchent effectivement dans le choix de migrer ou non vers les standards. D'ailleurs, si quelqu'un a déjà lu un article sur la bonne façon de coder le javascript, le html et le xsl, qu'il n'hésite pas à se manifester.

[jv2759]

Ces quelques mises au point étaient nécessaires, et penchent effectivement dans le choix de migrer ou non vers les standards. D'ailleurs, si quelqu'un a déjà lu un article sur la bonne façon de coder le javascript, le html et le xsl, qu'il n'hésite pas à se manifester.

LA reference... On peux même trouver en cherchant des vf...

http://w3c.org/

sinon des lien interessant :

http://www.geckozone.org/forum/viewtopic.php?t=13

L'application en question est exclusivement utilisée en interne par des ordinateurs dont la mise à jour anti virale se fait au moins une fois par jour sur l'ensemble des machines connectées sur notre réseau. L'antivirus en question sait repérer les exploits de ce genre et les stopper (cas déjà vécu il y a quelques jours avec SOBER.I)

Mais quand serat-il de demain? S'il y as une faille et que l'antivirus ne peux même pas coriger, ou quoi qu'il puisse arriver? Tu dirat au utilisateur utiliser firefox pour naviguer et ie pour nos application interne?

Là vous ête prisonier de votre application. Certe aujourd'hui cela ne vous pause pas trop de probléme. Mais demain? Si pour plein de raison firefox continut à vraiment persser et ce n'est plus simplement percer, mais il s'impose, 80% des utilisateur (ok je reve un peux). Tu vas dire à vos colaborateur et à vos client. Non vous ne pouver pas utiliser firefox, il faut continuer à utiliser ie...

Le web à un avantage c'est qu'il est independant de la plateforme et des logiciel. Dans le cas d'un code ie-only, on fait marche arriére car on ne peux plus quitter ie...

Franchement quitte à faire une application, qui ne marche qu'en environement définit, alors il vaux mieux faire une vrais application en dephi, vb, c builder, java...

[shiftcode]

LA reference... On peux même trouver en cherchant des vf...

http://w3c.org/

Assomant, manque de concision; moi je veux juste quelques conseils.

Tu vas dire à vos colaborateur et à vos client. Non vous ne pouver pas utiliser firefox, il faut continuer à utiliser ie...

Là, tu m'as convaincu.

Franchement quitte à faire une application, qui ne marche qu'en environement définit, alors il vaux mieux faire une vrais application en dephi, vb, c builder, java...

Par contre là, permets-moi de te dire que je te désapprouve totalement! Développer en client-serveur impose des contraintes de déploiement des nouvelles versions sur tous les postes de la société (150), tout çà quelque fois juste pour corriger un bug. On a déjà assez d'applications de ce genre pour éviter d'écrire les nôtres! L'un des avantages du duo client léger-serveur web, c'est que l'application réside sur le serveur, et peut être corrigée finement sans avoir à redéployer l'application sur tous les postes.