Guy a écrit :
> Bruno Desthuilliers a écrit :
>> ASM a écrit :
>>
>>> Bruno Desthuilliers a écrit :
>>>
>>>> rico a écrit :
>>>>
>>>>> "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 !

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 ?

Laurent vilday a écrit :
> Bruno Desthuilliers a écrit :
>> ASM a écrit :
>>> Bruno Desthuilliers a écrit :
>>>> 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.

Laurent vilday a écrit :
> Bruno Desthuilliers a écrit :
>> ASM a écrit :
>>> Bruno Desthuilliers a écrit :
>>>> 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.

Bruno Desthuilliers a écrit :
> ASM a écrit :
>> Bruno Desthuilliers a écrit :
>>> ASM a écrit :
>> "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/>
>
> 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

Bruno Desthuilliers a écrit :
> Guy a écrit :
>> Bruno Desthuilliers a écrit :
>>> ASM a écrit :
>>>
>>>> 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

Bruno Desthuilliers a écrit :
> Guy a écrit :
>> Bruno Desthuilliers a écrit :
>>> ASM a écrit :
>>>
>>>> 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

Bruno Desthuilliers a écrit :
>
> 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

Bruno Desthuilliers a écrit :
>
> 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

Laurent vilday a écrit :
>
> 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

Bruno Desthuilliers a écrit :
>
> 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

Bruno Desthuilliers a écrit :
>
> 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.

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 a écrit :
> "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

rico a écrit :
> "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

Laurent vilday a écrit :
> Guy a écrit :
>
>> 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
>
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

Laurent vilday a écrit :
> Guy a écrit :
>
>> 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
>
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

ASM a écrit :
> Bruno Desthuilliers a écrit :
>> ASM a écrit :
>>> Bruno Desthuilliers a écrit :
>>>> ASM a écrit :
>>> "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.

ASM a écrit :
> Bruno Desthuilliers a écrit :
>> ASM a écrit :
>>> Bruno Desthuilliers a écrit :
>>>> ASM a écrit :
>>> "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.

ASM a écrit :
> Bruno Desthuilliers a écrit :
>> Guy a écrit :
>>> Bruno Desthuilliers a écrit :
>>>> ASM a écrit :
>>>>
>>>>> 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...

ASM a écrit :
> Bruno Desthuilliers a écrit :
>> Guy a écrit :
>>> Bruno Desthuilliers a écrit :
>>>> ASM a écrit :
>>>>
>>>>> 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...