Je pense, sans vouloir t'offenser, que tu es resté sur une image de JS d'il y a 5 ans.
Je suis sur un projet ou je suis à 6000 lignes de code JS.
Il y a moins de 150 (je crois) lignes qui concerne un contournement de comportement different entre navigateur.
C'est surtout lié à des problèmes de listening. Mais un fois mis l'abstraction la dessus, je ne fais plus de code spécifique.
Tout est codé en objet, dans des (pseudo) classes à la Java, documenté grace à javadoc,etc...
D'ailleurs, mes classes java coté tomcat "discute" de manière quasi transparente avec le coté client, en JS.
Debuger avec la function alert... C'est un peu oldy, non ?
Au pire, firebug est magnifique pour ce boulot, au mieux, tu fais comme je fais :
Un system de log, qui sois affiche les logs dans un div, sois les envois dans POST en asynchrone. Comme ça tu peux les pousser coté serveur et faire mumuse avec.
Encore une fois, aucune différence avec un autre langage, c'est logs, ça se traite et c'est tout. C'est franchement très simple de se faire une fonction log(message) en javascript.
Je ne connais pas Eclipse, mais NetBeans integre le JS très bien. Il possede un explorateur de (pseudo) classes, completion, détection de certaine erreur, un peu de refactor, etc.
Ton problème de formulaire ne peut pas se regler avec des onblur="check(this.value)" onchange="check(this.value)" onkeyup="check(this.value)" ?
Le probleme de javascript, il est souvent assis sur la chaise. C'est un langage relégué au petite tache alors qu'il à un enorme potentiel si on pense l'application comme un tout. Le coté serveur ET la partie cliente. Et l'on gagne du temps.
exemple :
Un objet coté serveur de type user ?
on créer une fonction user.toXML().
On créer le même objet coté javascript.
on créer une fonction user.setByXML()
on créer une fonction user.toDiv(), et hop, a chaque fois que l'on veut afficher un user sur le site, y a plus qu'a.
ça reduit la charge, ça simplifie, etc...
Bien sur c'est un exemple bidon, mais ça s'adapte vite.
Il faut juste arreter de penser un site comme juste la partie serveur. L'affichage, c'est la partie client, c'est tout.
[^] # Re: Et pourquoi diable
Posté par kowalsky . En réponse au journal framework ou farmer ?. Évalué à 6.
Je suis sur un projet ou je suis à 6000 lignes de code JS.
Il y a moins de 150 (je crois) lignes qui concerne un contournement de comportement different entre navigateur.
C'est surtout lié à des problèmes de listening. Mais un fois mis l'abstraction la dessus, je ne fais plus de code spécifique.
Tout est codé en objet, dans des (pseudo) classes à la Java, documenté grace à javadoc,etc...
D'ailleurs, mes classes java coté tomcat "discute" de manière quasi transparente avec le coté client, en JS.
Debuger avec la function alert... C'est un peu oldy, non ?
Au pire, firebug est magnifique pour ce boulot, au mieux, tu fais comme je fais :
Un system de log, qui sois affiche les logs dans un div, sois les envois dans POST en asynchrone. Comme ça tu peux les pousser coté serveur et faire mumuse avec.
Encore une fois, aucune différence avec un autre langage, c'est logs, ça se traite et c'est tout. C'est franchement très simple de se faire une fonction log(message) en javascript.
Je ne connais pas Eclipse, mais NetBeans integre le JS très bien. Il possede un explorateur de (pseudo) classes, completion, détection de certaine erreur, un peu de refactor, etc.
Ton problème de formulaire ne peut pas se regler avec des onblur="check(this.value)" onchange="check(this.value)" onkeyup="check(this.value)" ?
Le probleme de javascript, il est souvent assis sur la chaise. C'est un langage relégué au petite tache alors qu'il à un enorme potentiel si on pense l'application comme un tout. Le coté serveur ET la partie cliente. Et l'on gagne du temps.
exemple :
Un objet coté serveur de type user ?
on créer une fonction user.toXML().
On créer le même objet coté javascript.
on créer une fonction user.setByXML()
on créer une fonction user.toDiv(), et hop, a chaque fois que l'on veut afficher un user sur le site, y a plus qu'a.
ça reduit la charge, ça simplifie, etc...
Bien sur c'est un exemple bidon, mais ça s'adapte vite.
Il faut juste arreter de penser un site comme juste la partie serveur. L'affichage, c'est la partie client, c'est tout.