par
Berzemus » 05 avr. 2010, 14:02
mais tous les navigateurs le comprennent-ils aussi bien que les <tables> ?
Ouh, le réflexe de vieux briscard

... Ben ouais, on n'est plus en 2005.. IE6 se rencontre encore parfois, mais de nos jours, quasi tous les navigateurs se battent pour respecter au plus près les standards (ou d'au moins réussir les tests mieux que les autres). Ce n'est pas encore "parfait", mais parfaitement gérable.
Je n'aime pas trop le javascript, parce que c'est exécuter sur le poste client, donc ça peut réagir différemment sur un pc ou un autre (et ça s'est frustrant)
Haha, réflexe de briscard 2... a vrai dire, ça doit faire 4 ou 5 ans que je n'ais plus connus d'incompatibilité entre navigateurs (peut-être du fait que j'utilise plus Jquery, qui me permet d'oublier jusqu'à l'existence de traitements différents). A la limité une bizzarerie ou autre (firefox qui accepte l'absence de ; en fin de ligne la ou IE6 tique), mais avec des outils comme firebug et les débogueurs intégrés à IE8, c'est très aisé.
Et du traitement côté client, c'est du traitement serveur épargné (d'ailleurs, dans mes dernières applications c'est quasi du HTML statique qui est servi, le reste de la page étant mis à jour directement par JS, avec les données transitant en JSON vers des pages dédiées en PHP.
Tout ce qui est métier reste côté serveur, mais tout ce qui est affichage se déroule côté client, les données transitant en brut en JSON ou XML.
ps: et pour continuer sur le "
JS, c'est plus que sympa" et "
ces 5 dernières années, JS s'est profilé comme une langage de plus en plus professionnel et performant)", une de mes applis se contentait d'une page Html
vide, avec juste un seul lien vers un script JS d'initialisation. Celui-ci se chargeait de tout mettre en place, l'application étant 100% javascript, le JS interrogeant directement la DB par Http (CouchDB fonctionne ainsi), qui répondait en JSon. Du coup, le serveur n'avait comme unique charge que la base de données, tout le reste étant côté client (et on aurait tort de ne pas profiter des performances de plus en plus élevées des postes clients).
Et l'appli tourne très bien sur tous les navigateurs

[quote="PowOx"] mais tous les navigateurs le comprennent-ils aussi bien que les <tables> ? [/quote]
Ouh, le réflexe de vieux briscard :mrgreen: ... Ben ouais, on n'est plus en 2005.. IE6 se rencontre encore parfois, mais de nos jours, quasi tous les navigateurs se battent pour respecter au plus près les standards (ou d'au moins réussir les tests mieux que les autres). Ce n'est pas encore "parfait", mais parfaitement gérable.
[quote="PowOx"]Je n'aime pas trop le javascript, parce que c'est exécuter sur le poste client, donc ça peut réagir différemment sur un pc ou un autre (et ça s'est frustrant)[/quote]
Haha, réflexe de briscard 2... a vrai dire, ça doit faire 4 ou 5 ans que je n'ais plus connus d'incompatibilité entre navigateurs (peut-être du fait que j'utilise plus Jquery, qui me permet d'oublier jusqu'à l'existence de traitements différents). A la limité une bizzarerie ou autre (firefox qui accepte l'absence de ; en fin de ligne la ou IE6 tique), mais avec des outils comme firebug et les débogueurs intégrés à IE8, c'est très aisé.
Et du traitement côté client, c'est du traitement serveur épargné (d'ailleurs, dans mes dernières applications c'est quasi du HTML statique qui est servi, le reste de la page étant mis à jour directement par JS, avec les données transitant en JSON vers des pages dédiées en PHP.
Tout ce qui est métier reste côté serveur, mais tout ce qui est affichage se déroule côté client, les données transitant en brut en JSON ou XML.
ps: et pour continuer sur le "[i]JS, c'est plus que sympa[/i]" et "[i]ces 5 dernières années, JS s'est profilé comme une langage de plus en plus professionnel et performant)[/i]", une de mes applis se contentait d'une page Html [b]vide[/b], avec juste un seul lien vers un script JS d'initialisation. Celui-ci se chargeait de tout mettre en place, l'application étant 100% javascript, le JS interrogeant directement la DB par Http (CouchDB fonctionne ainsi), qui répondait en JSon. Du coup, le serveur n'avait comme unique charge que la base de données, tout le reste étant côté client (et on aurait tort de ne pas profiter des performances de plus en plus élevées des postes clients).
Et l'appli tourne très bien sur tous les navigateurs 8-)