il est évident que le DOM permet la construction de page éminemment
dynamique ! Mais quelle est la raison qui justifie, dans une page
formulaire, l'ajout de code HTML à la suite d'un textarea ?
il est évident que le DOM permet la construction de page éminemment
dynamique ! Mais quelle est la raison qui justifie, dans une page
formulaire, l'ajout de code HTML à la suite d'un textarea ?
il est évident que le DOM permet la construction de page éminemment
dynamique ! Mais quelle est la raison qui justifie, dans une page
formulaire, l'ajout de code HTML à la suite d'un textarea ?
Accessoirement, il existe des bibliothèques comme Prototype, JQuery
ou Mochikit qui simplifient énormément ce genre de traitements...
Heu ... si on n'y comprend pas trop en JS, je me demande comment on va
se dépatouiller d'usines à gaz ...
En ce qui concerne Prototype et Mochikit, ça aurait plutôt tendance à
*simplifier* l'utilisation de javascript AMHA.
Accessoirement, il existe des bibliothèques comme Prototype, JQuery
ou Mochikit qui simplifient énormément ce genre de traitements...
Heu ... si on n'y comprend pas trop en JS, je me demande comment on va
se dépatouiller d'usines à gaz ...
En ce qui concerne Prototype et Mochikit, ça aurait plutôt tendance à
*simplifier* l'utilisation de javascript AMHA.
Accessoirement, il existe des bibliothèques comme Prototype, JQuery
ou Mochikit qui simplifient énormément ce genre de traitements...
Heu ... si on n'y comprend pas trop en JS, je me demande comment on va
se dépatouiller d'usines à gaz ...
En ce qui concerne Prototype et Mochikit, ça aurait plutôt tendance à
*simplifier* l'utilisation de javascript AMHA.
A mon idée, il vaut mieux utiliser une bibliothèque déjà bien conçue et
activement maintenue plutôt que de réinventer la roue.
A mon idée, il vaut mieux utiliser une bibliothèque déjà bien conçue et
activement maintenue plutôt que de réinventer la roue.
A mon idée, il vaut mieux utiliser une bibliothèque déjà bien conçue et
activement maintenue plutôt que de réinventer la roue.
A mon idée, il vaut mieux utiliser une bibliothèque déjà bien conçue
et activement maintenue plutôt que de réinventer la roue.
Mouais.
Déjà, comment on détermine qu'une bibliothèque est bien conçue ? Surtout
quand on connait rien à JS ?
Ensuite, la diversité c'est mieux ! Heureusement que certains
réinventent régulièrement la roue, sinon on n'aurait qu'une seule roue
de disponible.
Si les autres réinventent la roue, pourquoi pas moi ? Ma roue est peut
être moins carrée.
A mon idée, il vaut mieux utiliser une bibliothèque déjà bien conçue
et activement maintenue plutôt que de réinventer la roue.
Mouais.
Déjà, comment on détermine qu'une bibliothèque est bien conçue ? Surtout
quand on connait rien à JS ?
Ensuite, la diversité c'est mieux ! Heureusement que certains
réinventent régulièrement la roue, sinon on n'aurait qu'une seule roue
de disponible.
Si les autres réinventent la roue, pourquoi pas moi ? Ma roue est peut
être moins carrée.
A mon idée, il vaut mieux utiliser une bibliothèque déjà bien conçue
et activement maintenue plutôt que de réinventer la roue.
Mouais.
Déjà, comment on détermine qu'une bibliothèque est bien conçue ? Surtout
quand on connait rien à JS ?
Ensuite, la diversité c'est mieux ! Heureusement que certains
réinventent régulièrement la roue, sinon on n'aurait qu'une seule roue
de disponible.
Si les autres réinventent la roue, pourquoi pas moi ? Ma roue est peut
être moins carrée.
"rico" a écrit dans le message de news:
j'ai trouvé finalement: innerHTML !
Accessoirement, il existe des bibliothèques comme Prototype, JQuery
ou Mochikit qui simplifient énormément ce genre de traitements...
Heu ... si on n'y comprend pas trop en JS, je me demande comment on
va se dépatouiller d'usines à gaz ...
En ce qui concerne Prototype et Mochikit, ça aurait plutôt tendance à
*simplifier* l'utilisation de javascript AMHA. Et le terme d'usine à
gaz me semble très exagéré. N'aurais-tu pas comme un a priori, là ?
La question posée par ASM mérite réponse et je me permets de la
reformuler :
il est évident que le DOM permet la construction de page éminemment
dynamique !
Mais quelle est la raison qui justifie, dans une page
formulaire, l'ajout de code HTML à la suite d'un textarea ?
"rico" <z66z@hotmail.com> a écrit dans le message de news:
j'ai trouvé finalement: innerHTML !
Accessoirement, il existe des bibliothèques comme Prototype, JQuery
ou Mochikit qui simplifient énormément ce genre de traitements...
Heu ... si on n'y comprend pas trop en JS, je me demande comment on
va se dépatouiller d'usines à gaz ...
En ce qui concerne Prototype et Mochikit, ça aurait plutôt tendance à
*simplifier* l'utilisation de javascript AMHA. Et le terme d'usine à
gaz me semble très exagéré. N'aurais-tu pas comme un a priori, là ?
La question posée par ASM mérite réponse et je me permets de la
reformuler :
il est évident que le DOM permet la construction de page éminemment
dynamique !
Mais quelle est la raison qui justifie, dans une page
formulaire, l'ajout de code HTML à la suite d'un textarea ?
"rico" a écrit dans le message de news:
j'ai trouvé finalement: innerHTML !
Accessoirement, il existe des bibliothèques comme Prototype, JQuery
ou Mochikit qui simplifient énormément ce genre de traitements...
Heu ... si on n'y comprend pas trop en JS, je me demande comment on
va se dépatouiller d'usines à gaz ...
En ce qui concerne Prototype et Mochikit, ça aurait plutôt tendance à
*simplifier* l'utilisation de javascript AMHA. Et le terme d'usine à
gaz me semble très exagéré. N'aurais-tu pas comme un a priori, là ?
La question posée par ASM mérite réponse et je me permets de la
reformuler :
il est évident que le DOM permet la construction de page éminemment
dynamique !
Mais quelle est la raison qui justifie, dans une page
formulaire, l'ajout de code HTML à la suite d'un textarea ?
Accessoirement, il existe des bibliothèques comme Prototype, JQuery
ou Mochikit qui simplifient énormément ce genre de traitements...
Heu ... si on n'y comprend pas trop en JS, je me demande comment on
va se dépatouiller d'usines à gaz ...
En ce qui concerne Prototype et Mochikit, ça aurait plutôt tendance à
*simplifier* l'utilisation de javascript AMHA.
Je ne suis pas d'accord. Si on ne comprend pas trop JS, il est fortement
recommandé de ne *PAS* utiliser Prototype, Mochikit et autres jQuery.
Pourquoi ?
Simplement parce que l'utilisation de ces librairies a tendance à nous
faire développer à la sauce définie par la librairie. Et donc, on a
aucune chance d'apprendre et *comprendre* le fonctionnement de JS.
On saura faire du JS façon Prototype, ou du JS façon jQuery, mais en
aucune manière du JS façon JS !
Certes les librairies aident (peuvent aider) à réduire le code
spécifique à chaque navigateur,
mais le jour ou la librairie ne peut pas
être utilisée pour une raison X ou Y,
et bien on est tout penaud devant
le <script></script> qu'on est incapable de remplir.
Une fois que JS est compris, pourquoi pas aller voir les librairies,
d'accord. Mais tant qu'on y comprend rien, non, il ne faut pas les
utiliser, il faut se limiter aux besoins basiques qu'on a avec du bon JS
de grand mère.
Accessoirement, il existe des bibliothèques comme Prototype, JQuery
ou Mochikit qui simplifient énormément ce genre de traitements...
Heu ... si on n'y comprend pas trop en JS, je me demande comment on
va se dépatouiller d'usines à gaz ...
En ce qui concerne Prototype et Mochikit, ça aurait plutôt tendance à
*simplifier* l'utilisation de javascript AMHA.
Je ne suis pas d'accord. Si on ne comprend pas trop JS, il est fortement
recommandé de ne *PAS* utiliser Prototype, Mochikit et autres jQuery.
Pourquoi ?
Simplement parce que l'utilisation de ces librairies a tendance à nous
faire développer à la sauce définie par la librairie. Et donc, on a
aucune chance d'apprendre et *comprendre* le fonctionnement de JS.
On saura faire du JS façon Prototype, ou du JS façon jQuery, mais en
aucune manière du JS façon JS !
Certes les librairies aident (peuvent aider) à réduire le code
spécifique à chaque navigateur,
mais le jour ou la librairie ne peut pas
être utilisée pour une raison X ou Y,
et bien on est tout penaud devant
le <script></script> qu'on est incapable de remplir.
Une fois que JS est compris, pourquoi pas aller voir les librairies,
d'accord. Mais tant qu'on y comprend rien, non, il ne faut pas les
utiliser, il faut se limiter aux besoins basiques qu'on a avec du bon JS
de grand mère.
Accessoirement, il existe des bibliothèques comme Prototype, JQuery
ou Mochikit qui simplifient énormément ce genre de traitements...
Heu ... si on n'y comprend pas trop en JS, je me demande comment on
va se dépatouiller d'usines à gaz ...
En ce qui concerne Prototype et Mochikit, ça aurait plutôt tendance à
*simplifier* l'utilisation de javascript AMHA.
Je ne suis pas d'accord. Si on ne comprend pas trop JS, il est fortement
recommandé de ne *PAS* utiliser Prototype, Mochikit et autres jQuery.
Pourquoi ?
Simplement parce que l'utilisation de ces librairies a tendance à nous
faire développer à la sauce définie par la librairie. Et donc, on a
aucune chance d'apprendre et *comprendre* le fonctionnement de JS.
On saura faire du JS façon Prototype, ou du JS façon jQuery, mais en
aucune manière du JS façon JS !
Certes les librairies aident (peuvent aider) à réduire le code
spécifique à chaque navigateur,
mais le jour ou la librairie ne peut pas
être utilisée pour une raison X ou Y,
et bien on est tout penaud devant
le <script></script> qu'on est incapable de remplir.
Une fois que JS est compris, pourquoi pas aller voir les librairies,
d'accord. Mais tant qu'on y comprend rien, non, il ne faut pas les
utiliser, il faut se limiter aux besoins basiques qu'on a avec du bon JS
de grand mère.
"simplifier" tout en "compliquant" (les docs sont quasi innexistantes)
Pardon ???
http://www.prototypejs.org/api
http://www.prototypejs.org/learn
http://mochikit.com/doc/html/MochiKit/index.html
http://docs.jquery.com/Main_Page
T'es carrément de mauvaise foi, là.
- Oui j'ai un très très fort à priori.
Ca se voit.
(renforcé par ma pas si vieille expérience du RTC)
- Attends ! charger 96ko d'une usine (prototype)
qui intègre aussi l'Ajax pour, finalement,
n'utiliser que $(), $F(), et peut-être each() .... ? ?
T'inquiète, t'a vite fait d'en utiliser bien plus, même si tu ne fais
pas d'ajax.
Ha! j'ai enfin trouvé une doc en français (bon, ce n'est pas la
dernière version de prototype, mais ça peut aider)
<http://dcabasson.developpez.com/articles/javascript/ajax/documentation-prototype-1.4.0/>
Tu ne lis pas l'anglais technique ???
Question :
Prototype, tout un tas de monde s'en sert, donc normalement il devrait
être en cache,
Ah ???
comment se passe la gestion du cache alors qu'il y a je ne sais
combien de versions de prototype qui errent de par le Net ?
Ca marche comme pour n'importe quelle autre ressource.
"simplifier" tout en "compliquant" (les docs sont quasi innexistantes)
Pardon ???
http://www.prototypejs.org/api
http://www.prototypejs.org/learn
http://mochikit.com/doc/html/MochiKit/index.html
http://docs.jquery.com/Main_Page
T'es carrément de mauvaise foi, là.
- Oui j'ai un très très fort à priori.
Ca se voit.
(renforcé par ma pas si vieille expérience du RTC)
- Attends ! charger 96ko d'une usine (prototype)
qui intègre aussi l'Ajax pour, finalement,
n'utiliser que $(), $F(), et peut-être each() .... ? ?
T'inquiète, t'a vite fait d'en utiliser bien plus, même si tu ne fais
pas d'ajax.
Ha! j'ai enfin trouvé une doc en français (bon, ce n'est pas la
dernière version de prototype, mais ça peut aider)
<http://dcabasson.developpez.com/articles/javascript/ajax/documentation-prototype-1.4.0/>
Tu ne lis pas l'anglais technique ???
Question :
Prototype, tout un tas de monde s'en sert, donc normalement il devrait
être en cache,
Ah ???
comment se passe la gestion du cache alors qu'il y a je ne sais
combien de versions de prototype qui errent de par le Net ?
Ca marche comme pour n'importe quelle autre ressource.
"simplifier" tout en "compliquant" (les docs sont quasi innexistantes)
Pardon ???
http://www.prototypejs.org/api
http://www.prototypejs.org/learn
http://mochikit.com/doc/html/MochiKit/index.html
http://docs.jquery.com/Main_Page
T'es carrément de mauvaise foi, là.
- Oui j'ai un très très fort à priori.
Ca se voit.
(renforcé par ma pas si vieille expérience du RTC)
- Attends ! charger 96ko d'une usine (prototype)
qui intègre aussi l'Ajax pour, finalement,
n'utiliser que $(), $F(), et peut-être each() .... ? ?
T'inquiète, t'a vite fait d'en utiliser bien plus, même si tu ne fais
pas d'ajax.
Ha! j'ai enfin trouvé une doc en français (bon, ce n'est pas la
dernière version de prototype, mais ça peut aider)
<http://dcabasson.developpez.com/articles/javascript/ajax/documentation-prototype-1.4.0/>
Tu ne lis pas l'anglais technique ???
Question :
Prototype, tout un tas de monde s'en sert, donc normalement il devrait
être en cache,
Ah ???
comment se passe la gestion du cache alors qu'il y a je ne sais
combien de versions de prototype qui errent de par le Net ?
Ca marche comme pour n'importe quelle autre ressource.
Heu ... si on n'y comprend pas trop en JS, je me demande comment on
va se dépatouiller d'usines à gaz ...
[...]
Mais quelle est la raison qui justifie, dans une page formulaire,
l'ajout de code HTML à la suite d'un textarea ?
Par exemple, transformer un textarea en éditeur wyswyg sans toucher au
source HTML ?
Heu ... si on n'y comprend pas trop en JS, je me demande comment on
va se dépatouiller d'usines à gaz ...
[...]
Mais quelle est la raison qui justifie, dans une page formulaire,
l'ajout de code HTML à la suite d'un textarea ?
Par exemple, transformer un textarea en éditeur wyswyg sans toucher au
source HTML ?
Heu ... si on n'y comprend pas trop en JS, je me demande comment on
va se dépatouiller d'usines à gaz ...
[...]
Mais quelle est la raison qui justifie, dans une page formulaire,
l'ajout de code HTML à la suite d'un textarea ?
Par exemple, transformer un textarea en éditeur wyswyg sans toucher au
source HTML ?
J'entend bien ton propos - d'autant que j'ai moi-même tendance à
préférer commencer par mettre les mains dans le cambouis au moins une ou
deux fois avant d'utiliser des outils de plus haut niveau - mais je ne
vois pas en quoi cela contredit mon propos. Compare le code pour faire
une requête XHR, générer des fragment de DOM à partir de la réponse et
les insérer dans le document avec et sans une de ces bibliothèques - il
est évident que c'est beaucoup plus simple avec.
Qu'est-ce que tu veux que je te dise... On est développeur ou on ne
l'est pas, et quand on ne l'est pas, soit on apprend soit on fait appel
à un développeur.
Mouais.... Vu le niveau moyen du "bon JS de grand-mère" que je vois en
prod, j'en arriverais presque à me demander si je ne préfèrerais pas que
les coupables aient utilisé, même sans bien la comprendre, une des
bibliothèques en question.
J'entend bien ton propos - d'autant que j'ai moi-même tendance à
préférer commencer par mettre les mains dans le cambouis au moins une ou
deux fois avant d'utiliser des outils de plus haut niveau - mais je ne
vois pas en quoi cela contredit mon propos. Compare le code pour faire
une requête XHR, générer des fragment de DOM à partir de la réponse et
les insérer dans le document avec et sans une de ces bibliothèques - il
est évident que c'est beaucoup plus simple avec.
Qu'est-ce que tu veux que je te dise... On est développeur ou on ne
l'est pas, et quand on ne l'est pas, soit on apprend soit on fait appel
à un développeur.
Mouais.... Vu le niveau moyen du "bon JS de grand-mère" que je vois en
prod, j'en arriverais presque à me demander si je ne préfèrerais pas que
les coupables aient utilisé, même sans bien la comprendre, une des
bibliothèques en question.
J'entend bien ton propos - d'autant que j'ai moi-même tendance à
préférer commencer par mettre les mains dans le cambouis au moins une ou
deux fois avant d'utiliser des outils de plus haut niveau - mais je ne
vois pas en quoi cela contredit mon propos. Compare le code pour faire
une requête XHR, générer des fragment de DOM à partir de la réponse et
les insérer dans le document avec et sans une de ces bibliothèques - il
est évident que c'est beaucoup plus simple avec.
Qu'est-ce que tu veux que je te dise... On est développeur ou on ne
l'est pas, et quand on ne l'est pas, soit on apprend soit on fait appel
à un développeur.
Mouais.... Vu le niveau moyen du "bon JS de grand-mère" que je vois en
prod, j'en arriverais presque à me demander si je ne préfèrerais pas que
les coupables aient utilisé, même sans bien la comprendre, une des
bibliothèques en question.
Voila, imo, une raison justifiant l'ajout dynamique a la suite d'un
<textarea> ou <input type=text>.
Voila, imo, une raison justifiant l'ajout dynamique a la suite d'un
<textarea> ou <input type=text>.
Voila, imo, une raison justifiant l'ajout dynamique a la suite d'un
<textarea> ou <input type=text>.