Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

ajouter automatiquement du code HTML juste derriere tous les textareas d'une page

46 réponses
Avatar
rico
salut,

je suis plutot débutant en javascript et je n'arrive pas à faire ceci:
ajouter automatiquement du code HTML juste derriere tous les textareas d'une
page.

y a-t-il une âme charitable pour m'aiguiller ?

rico

10 réponses

1 2 3 4 5
Avatar
Laurent vilday
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 peut y avoir des tonnes de raisons, et principalement celles
auxquelles on ne pense pas.

J'ai un exemple très concret que j'utilise dans mon appli qui permet
d'avoir visuellement un indicateur de maximum pour les <textarea> et les
<input type="text">.
Voici une version adaptée pour fciwa exposant la chose :
<http://mokhet.com/tests/add_element.html&gt;

Au début on a un formulaire simple avec des éléments X et Y, onload on
ajoute une barre de progression (cachée) pour indiquer si le maximum de
caractères est atteint. Sur le focus, la barre s'affiche et se remplit
au fur et à mesure qu'on tape des caractères dans le champ, sur le blur,
la barre disparait, sur le keypress l'indicateur est mis à jour et le
cas échéant, la valeur est tronquée si dépassant le maximum déclaré.

Voila, imo, une raison justifiant l'ajout dynamique a la suite d'un
<textarea> ou <input type=text>.

PS : oui je sais, le code est un peu fouilli et la détection des
positions est pas terrible sous IE6. Mais c'est pour l'exemple, c'est
fait à l'arrache et ça passe bien sous FX2 et Opéra9 donc basta IE6, va
mourrir :D

--
laurent

Avatar
Laurent vilday
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.

--
laurent



Avatar
Laurent vilday
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.

--
laurent

Avatar
Bruno Desthuilliers
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 ?


Bonne question. Peut-être que la tester est une bonne solution ?

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.


Tu notera que j'ai cité 3 bibliothèques différentes couvrant à peu près
le même périmètre. la sélection naturelle fera le tri s'il en est besoin...

Si les autres réinventent la roue, pourquoi pas moi ? Ma roue est peut
être moins carrée.


Si tu pense pouvoir faire mieux *et* que tu en a le temps, c'est très
bien. Une autre option est de contribuer activement à un des projets
existants.


Avatar
Bruno Desthuilliers



"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 !


Et accessoirement, certaines bibliothèques simplifient notoirement ce
travail.

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 ?





Avatar
Bruno Desthuilliers
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.


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.

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,


Pas seulement.

mais le jour ou la librairie ne peut pas
être utilisée pour une raison X ou Y,


Mmm... A quels exemples de X ou Y pense-tu ?

et bien on est tout penaud devant
le <script></script> qu'on est incapable de remplir.


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.

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.


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.




Avatar
ASM
"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à.


J'ai déjà visité ces pages.
De la doc en pas français n'est pas pour moi de la doc ... mais .. bon.

Oui je suis de mauvaise foi, je n'aime pas les biblis !
Bien que leurs éléments y contenus ne soient pas sans intéret.
En bref : je préfére qque chose constitué de sous-biblis
dont on ne fait charger que le nécessaire.


- Oui j'ai un très très fort à priori.


Ca se voit.


Ha! désolé d'être franc.

(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.


En général quand j'ai 20 à 25 ko de JS j'estime que j'ai fait très très
fort ! Que j'ai bien gavé la page html pour pas grand' chose. Enfin ...
pour qque chose, mais valait-ce vraiment la peine ?

L'Ajax ça ne pèse quand même pas tant que ça ... 2 3 routines JS et
roule ma poule. (ce me semble ...)

Si on a besoin exclusivement de JS (tout JS ?) ...
non,
merci de trouver une autre soluce.

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/&gt;


Tu ne lis pas l'anglais technique ???


Non !
C'est déjà bien assez compliqué en français pour mon dernier neurone
bien atteint !
Et y a rien qui m'exaspère plus que de visiter des sites francophones
(au vu de l'url) qui ne baragouinent qu'anglishe.

Question :
Prototype, tout un tas de monde s'en sert, donc normalement il devrait
être en cache,


Ah ???


ce serait l'idéal, non ?

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.


Je m'en doute bien et ça va bien dans mon sens : charger je ne sais
combien de ko de biblis pour ... finalement ... zapper la page qui
daigne enfin s'afficher ... non merci.


--
Stephane Moriaux et son vieux Mac


Avatar
ASM

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 ?


Ha oui ! le truc z'indispensable dans un formulaire ! :-)
(qui, quoiqu'on fasse, marchotera +/-)


Nota :
je ne vois pas en quoi l'usage d'une bibli permet mieux que du code
maison de faire du html propre ?



Surtout qu'une bibli n'est jamais qu'un ensemble de raccourcis (à chager
in-extenso) qui ne servira à rien si du code maison n'y fait pas suite
pour l'agiter.

Désolé mais y a pas : jurer par et pour les biblis je ne puis digérer.

--
Stephane Moriaux et son (moins) vieux Mac




Avatar
ASM

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.


Laquelle (pour ce cas de figure *exclusivement*) ?
Si possible avec un exemple concret.

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.


Ha ! Tiens ? y a pas que moi de mauvaise foi ! ? :-)

Qui a dit que le questionneur était "développeur" ?
(au sens où tu sembles l'entendre : professionnel)

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.


Oui et non, tout dépend du niveau d'exigences final du site.
"Ça marche chez moi, c'est OK" ou "Pas de retour négatif"

Néanmoins ... si "Pas de retour négatif", je suppose que les
"développeurs" sont de la partie et que donc ... ils savent se passer de
biblis et j'espère qu'on leur en laisse le moyen (temps de production).


--
Stephane Moriaux et son (moins) vieux Mac

Avatar
ASM

Voila, imo, une raison justifiant l'ajout dynamique a la suite d'un
<textarea> ou <input type=text>.


Ha! ce Laurent ! Il a toujours des tours dans son sac :-)

La question demeure posée : a-ton *besoin* de faire charger prototype
juste pour cette anecdote ?

Toi-même ne l'a pas fait, pourquoi ?

Tu rejoins donc ma façon de penser :
- quel est le besoin ? (dont on ne sais touj rien)
- voir à voir :
un peu de JS maison
ou bibli + JS maison quand même ?
(la bibli ne faisant rien par elle-même)



Corrélativement ces ajouts "dynamiques" étaient-ils vraiment
"indispensables", sinon même : seulement *"utiles"* ?

Est-ce que d'indiquer à côté du champ : "60 caractères maxi"
n'aurait pas suffit ?



--
Stephane Moriaux et son (moins) vieux Mac

1 2 3 4 5