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

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.

Si c'est pour y ajouter 10% de poids à chaque refonte, je prie Laurent
de s'en abstenir. (ce serait bien que les "actifs" en fassent autant)

Comme je ne cause pas anglais et que de ttes façons je n'ai pas le
niveau ... je ne risque pas de porter ombrage aux contributeurs actuels.
Qu'ils se rassurent :-)

--
Stephane Moriaux et son vieux Mac

"rico" <z66z@hotmail.com> a écrit dans le message de news:
4677f296$0$27388$ba4acef3@news.orange.fr...

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.

Salut,

Je vois que ça fait débat, donc voilà ce que je cherche à faire.

Il s'agit d'ajouter automatiquement des contrôles sur TOUT les textareas
d'un site intranet basés sur un CMS. Comme il y a plusieurs 10aines (voir
100aines de textareas), il est hors de question de modifier les code à
autant d'endroits, afin de conserver un maximum de compatibilité avec les
futurs évolutions du CMS. De plus, ce CMS peut intègrer des "pages" avec des
formulaires qui seront conçues par des non developpeurs (genre export word à
l'arrache ou autres trucs pas terribles).

Parmi les contrôles en question il y a Textarea tools
(http://livsey.org/experiments/textareatools/index.html) ou Googie Spell
(http://orangoo.com/labs/GoogieSpell/), ainsi que l'activation sur demande
d'un éditeur wysiwyg pour certains champs seulement.

Bref, finalement ça revient à à créer un module à intégrer au cms sans
toucher au reste.

Normalement ça n'étais pas à moi de faire la partie js car je n'y connais
rien...

rico

"rico" <z66z@hotmail.com> a écrit dans le message de news:
4677f296$0$27388$ba4acef3@news.orange.fr...

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.

Salut,

Je vois que ça fait débat, donc voilà ce que je cherche à faire.

Oui, eh ben finalement ce n'est pas tartignole (surtout pour qqu'un ne
connaissant rien au JS)

Il s'agit d'ajouter automatiquement des contrôles sur TOUT les textareas
d'un site intranet

Ha!
alors mon à priori négatif n'a plus lieu d'être, on peut bien faire
charger toutes les biblis qu'on veut.

basés sur un CMS.

déjà que tout le tremblement du CMS a été mis en branle, ce n'est plus à
qques centaines de ko près.

Comme il y a plusieurs 10aines (voir
100aines de textareas), il est hors de question de modifier les code à
autant d'endroits, afin de conserver un maximum de compatibilité avec les
futurs évolutions du CMS. De plus, ce CMS peut intègrer des "pages" avec des
formulaires qui seront conçues par des non developpeurs (genre export word à
l'arrache ou autres trucs pas terribles).

Boudiou ! Ayeaïeayaye.

Parmi les contrôles en question il y a Textarea tools
(http://livsey.org/experiments/textareatools/index.html)

Je ne comprends pas l'intéret de ces outils.

ou Googie Spell
(http://orangoo.com/labs/GoogieSpell/),

Ha! ça c'est génial là dis-donc !
(et le JS googlespell ne fait que 33ko)
Tiens ?
googlespell n'orthographie pas 'tartignolle' comme Thunderbird le fait!
(ils ont raison tous deux)
Mais, si j'ai bien compris, il faut être connecté à l'Internet et on est
à la merci d'une modif à l'insu de soi-même sur :
https://www.google.com/tbproxy/


--
Stephane Moriaux et son (moins) vieux Mac

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>

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

Bonjour,

rien à voir avec la demande "ajouter du HTML"
le cas que vous exposez (compter et comparer avec un limite max) peut
être traité par du JS pur et simple (interception d'événement, décompte
et modification de la page).
GR

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

Ah bin c'est sûr que vu sous cet angle, ça ne va pas aller loin.

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.

Alors contribue pour rendre une de ces bibliothèques plus modulaires...

- 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 ?

Quand tu développes une application (par opposition à une simple page
web), tu a vite fait - en tous cas si tu codes tout à la mano - de
dépasser les 25ko, lesquels contiennent une telle quantité de
boilerplate que très vite tu commences à te dire que ça mérite une bonne
factorisation... et voilà, t'a réinventé la roue - carrée de préférence.

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 ???

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.

Que ça fasse ton bonheur ou non, l'anglais est la lingua franca en
informatique.

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

Ah ???

ce serait l'idéal, non ?

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

Avec une machine qui n'a rien d'une bête de course (athlon XP1800) et
une connection adsl minimum, c'est tout à fait indolore.

non merci.

Tu n'a pas l'air de comprendre. Dans le cas le plus courant, la
ressource "/url/de/protoype.js" sera la même pour tout un domaine. Si tu
règles correctement ton serveur, elle devrait être cachée au premier
passage sur une page du site - pas besoin de la recharger avec chaque page.

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 +/-)

Outre le fait que certains de ces éditeurs fonctionnent assez
correctement, j'aimerais te signaler qu'en ce qui me concerne j'ai des
clients qui paient assez cher pour imposer l'emploi de ce genre de
choses - alors ton avis sur le côté indispensable ou non de la chose, si
tu veux, c'est un peu HS. A ce jeu là, ni JS ni les CMS n'ont rien
d'indispensable. Ni les langages de programmation évolués, tant qu'on y
est - allez, on va faire des cgi en assembleur...

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

Nota : je ne vois pas le rapport entre ton 'nota' et le post auquel tu
réponds.

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.

Non ? Sans blague ?

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

Je ne "jure par et pour" rien, je suis pragmatique, c'est tout. Que celà

ne t'empêche en aucun cas de continuer à ciseler du beau javascript à
l'ancienne...

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*) ?

N'importe laquelle des trois citées, et quelques autres encore. En ce
qui me concerne, ma préférence va pour le moment à prototype (entre
autres parce que c'est la plus couramment utilisée, ce qui m'évite de
devoir en apprendre une demi-douzaines par ailleurs sensiblement
équivalentes en termes de qualité et de fonctionnalité).

Si possible avec un exemple concret.

Désolé, pas que ça à faire. Ceci étant, tu trouvera ces exemples sur les
pages de doc "inexistantes".

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 ! ? :-)

Quelle mauvaise foi ?

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

Le sens où je l'entends, c'est "compétent". javascript est un langage de
programmation, c'est donc un outil pour développeur. Accessoirement, vu
les gotchas du langage (notamment au niveau des règles de portée et de
visibilité), ce n'est certainement pas le langage le plus accessible à
un débutant.

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"

Le "niveau d'exigeance final" du client, c'est de toutes façons que ça
marche sur les principaux navigateurs, et pour la plupart des
institutionnels (qui ont des contraintes en matière d'accessibilité) que
ça marche aussi sans javascript.

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

T'inquiètes.

et j'espère qu'on leur en laisse le moyen (temps de production).

Qu'on nous "laisse le temps" ? Tu rêves, là ou quoi ? Tu veux couler la
boite ??? On n'a pas de temps à perdre à réécrire ce qui existe déjà et
fonctionne bien.

Quand tu développes une application (par opposition à une simple page
web), tu a vite fait - en tous cas si tu codes tout à la mano - de
dépasser les 25ko,

Vu sous cet angle : OK.

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

ce serait l'idéal, non ?

Non.

Pourquoi ?
(hors incongruité de la ressource en un lieu non maitrisé)

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

Avec une machine qui n'a rien d'une bête de course (athlon XP1800) et
une connection adsl minimum, c'est tout à fait indolore.

Je n'ai pas d'athlon XP1800 (et ne sais pas ce que c'est)
mais je suis en ADSL 512
Tu as un peu raison, j'ai l'impression que dans le cas de JS lourds (2 à
300ko) je n'ai pas plus de lenteur que pour recevoir une page de 30 ko
toute mouillée en RTC.
Et c'est donc relativement indolore.
C'est juste une question de principe : je connais certains qui n'ont pas
l'ADSL.
En outre les JS n'ont pas été chargés pour rien, probablement ils vont
agiter un tas de choses comme de faire charger d'autres sources (ce qui
ne va pas accélérer l'affichage final).

non merci.

Tu n'a pas l'air de comprendre.

Non, tu me comprends mal : "non merci le truc *exclusif* JS"

Dans le cas le plus courant, la
ressource "/url/de/protoype.js" sera la même pour tout un domaine.

oui, mais j'aimerais n'avoir à ne la charger qu'après l'accueil et même
qu'après le menu. (ce serait sympa pour celui qui débarque et s'aperçoit
qu'il n'a rien à faire ici).
Car en général, la bibli n'est pas seule requise.

Si tu
règles correctement ton serveur, elle devrait être cachée au premier
passage sur une page du site - pas besoin de la recharger avec chaque page.

J'espère bien ! :-)


--
Stephane Moriaux et son (moins) vieux Mac

ma préférence va pour le moment à prototype (entre
autres parce que c'est la plus couramment utilisée, ce qui m'évite de
devoir en apprendre une demi-douzaines par ailleurs sensiblement
équivalentes en termes de qualité et de fonctionnalité).

vu.

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

Le sens où je l'entends, c'est "compétent".

Oui, bon, on est d'accord sur le sens général.

javascript est un langage de
programmation, c'est donc un outil pour développeur.
...

ce n'est certainement pas le langage le plus accessible à un débutant.

En tous cas il semble l'être de moins en moins.

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"

Le "niveau d'exigeance final" du client,

Je n'ai pas parlé de client(s).

et j'espère qu'on leur en laisse le moyen (temps de production).

Qu'on nous "laisse le temps" ? Tu rêves, là ou quoi ? Tu veux couler la
boite ???

:-)


--
Stephane Moriaux et son (moins) vieux Mac

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 +/-)

Outre le fait que certains de ces éditeurs fonctionnent assez
correctement,

Ha ! tu l'admets ! "assez" ...

j'aimerais te signaler qu'en ce qui me concerne j'ai des
clients qui paient assez cher pour imposer l'emploi de ce genre de
choses - alors ton avis sur le côté indispensable ou non de la chose, si
tu veux, c'est un peu HS. A ce jeu là, ni JS ni les CMS n'ont rien
d'indispensable.

Damned ! je me suis trahi ! :-)

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

Nota : je ne vois pas le rapport entre ton 'nota' et le post auquel tu
réponds.

Nota : il y a longtemps qu'on n'est plus en train de répondre au post
initial

Pour info : je réponds à

Par exemple, transformer un textarea en éditeur wyswyg sans toucher
au source HTML ?

--
Stephane Moriaux et son (moins) vieux Mac