ajouter automatiquement du code HTML juste derriere tous les textareas d'une page
46 réponses
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.
Le 25/06/2007 13:49, ASM répondait à Bruno Desthuilliers :
D'autre part, le recours à Ajax permet d'éviter des rechargements *complets* de la page, et donc, une fois la bibliothèque montée en cache, un net gain de perfs *particulièrement* pour ceux qui ont un faible débit. Oui.
Mais l'Ajax (basique XHR) ce n'est que 10 à 20 ko maxi ... me semble-ce.
C'est quoi, les 10 ou 20 ko dont tu parles ? La taille supplémentaire de l'interpréteur JavaScript pour qu'il reconnaisse XMLHttpRequest ? La taille d'un code JavaScript à télécharger pour que l'on puisse vraiment parler d'« Ajax » au lieu de « XMLHttpRequest » ?
Je n'ai en fait jamais compris la différence qu'il y a entre XHR et Ajax,
Et pour cause : fondamentalement, y'en a pas. Mais Ajax, ça le fait vachement plus pour impressionner le gogo !-)
si ce n'est que celui-ci a un nom plus facile à retenir que celui-là (et plus rapide à taper si on veut l'écrire en entier).
Le 25/06/2007 13:49, ASM répondait à Bruno Desthuilliers :
D'autre part, le recours à Ajax permet d'éviter des rechargements
*complets* de la page, et donc, une fois la bibliothèque montée en
cache, un net gain de perfs *particulièrement* pour ceux qui ont un
faible débit.
Oui.
Mais l'Ajax (basique XHR) ce n'est que 10 à 20 ko maxi
... me semble-ce.
C'est quoi, les 10 ou 20 ko dont tu parles ? La taille supplémentaire
de l'interpréteur JavaScript pour qu'il reconnaisse XMLHttpRequest ?
La taille d'un code JavaScript à télécharger pour que l'on puisse
vraiment parler d'« Ajax » au lieu de « XMLHttpRequest » ?
Je n'ai en fait jamais compris la différence qu'il y a entre XHR et
Ajax,
Et pour cause : fondamentalement, y'en a pas. Mais Ajax, ça le fait
vachement plus pour impressionner le gogo !-)
si ce n'est que celui-ci a un nom plus facile à retenir que
celui-là (et plus rapide à taper si on veut l'écrire en entier).
Le 25/06/2007 13:49, ASM répondait à Bruno Desthuilliers :
D'autre part, le recours à Ajax permet d'éviter des rechargements *complets* de la page, et donc, une fois la bibliothèque montée en cache, un net gain de perfs *particulièrement* pour ceux qui ont un faible débit. Oui.
Mais l'Ajax (basique XHR) ce n'est que 10 à 20 ko maxi ... me semble-ce.
C'est quoi, les 10 ou 20 ko dont tu parles ? La taille supplémentaire de l'interpréteur JavaScript pour qu'il reconnaisse XMLHttpRequest ? La taille d'un code JavaScript à télécharger pour que l'on puisse vraiment parler d'« Ajax » au lieu de « XMLHttpRequest » ?
Je n'ai en fait jamais compris la différence qu'il y a entre XHR et Ajax,
Et pour cause : fondamentalement, y'en a pas. Mais Ajax, ça le fait vachement plus pour impressionner le gogo !-)
si ce n'est que celui-ci a un nom plus facile à retenir que celui-là (et plus rapide à taper si on veut l'écrire en entier).
Pierre Goiffon
ASM wrote:
Prototype, tout un tas de monde s'en sert, donc normalement il devrait être en cache, 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 ?
Le cache se réfère par rapport à une URL donnée.
A noter l'initiative de Yahoo qui propose un hébergement de sa librairie YUI : http://developer.yahoo.com/yui/articles/hosting/
ASM wrote:
Prototype, tout un tas de monde s'en sert, donc normalement il devrait
être en cache, 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 ?
Le cache se réfère par rapport à une URL donnée.
A noter l'initiative de Yahoo qui propose un hébergement de sa librairie
YUI :
http://developer.yahoo.com/yui/articles/hosting/
Prototype, tout un tas de monde s'en sert, donc normalement il devrait être en cache, 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 ?
Le cache se réfère par rapport à une URL donnée.
A noter l'initiative de Yahoo qui propose un hébergement de sa librairie YUI : http://developer.yahoo.com/yui/articles/hosting/
Bruno Desthuilliers
(snip)
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.
Le fait d'utiliser un CMS n'implique pas que les pages générées soient plus lourdes. C'est totalement orthogonal.
(snip)
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.
Je comprend au moins l'intérêt du redimensionnement d'une textarea.
(snip)
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.
Le fait d'utiliser un CMS n'implique pas que les pages générées soient
plus lourdes. C'est totalement orthogonal.
(snip)
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.
Je comprend au moins l'intérêt du redimensionnement d'une textarea.
déjà que tout le tremblement du CMS a été mis en branle, ce n'est plus à qques centaines de ko près.
Le fait d'utiliser un CMS n'implique pas que les pages générées soient plus lourdes. C'est totalement orthogonal.
(snip)
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.
Je comprend au moins l'intérêt du redimensionnement d'une textarea.
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> 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).
Pardon ? Je sais même pas comment exprimé mon désarroi devant une telle remarque !
Du JS pur et simple, pfff, n'importe quoi. Il faut au moins une entrée ou une sortie HTML pour que ça rime à qqchose.
Et évidemment qu'il faut du JS pour manipuler le code HTML ajouter après/avant/a la place d'un élément (textarea dans le cas de l'OP). HTML/JS/CSS sont évidemment *très* étroitement liés dès lors qu'on touche un peu au dynamisme.
M'enfin, allons voir ailleurs si qqchose de plus constructif est sorti de ce thread.
-- laurent
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>
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).
Pardon ? Je sais même pas comment exprimé mon désarroi devant une telle
remarque !
Du JS pur et simple, pfff, n'importe quoi. Il faut au moins une entrée
ou une sortie HTML pour que ça rime à qqchose.
Et évidemment qu'il faut du JS pour manipuler le code HTML ajouter
après/avant/a la place d'un élément (textarea dans le cas de l'OP).
HTML/JS/CSS sont évidemment *très* étroitement liés dès lors qu'on
touche un peu au dynamisme.
M'enfin, allons voir ailleurs si qqchose de plus constructif est sorti
de ce thread.
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> 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).
Pardon ? Je sais même pas comment exprimé mon désarroi devant une telle remarque !
Du JS pur et simple, pfff, n'importe quoi. Il faut au moins une entrée ou une sortie HTML pour que ça rime à qqchose.
Et évidemment qu'il faut du JS pour manipuler le code HTML ajouter après/avant/a la place d'un élément (textarea dans le cas de l'OP). HTML/JS/CSS sont évidemment *très* étroitement liés dès lors qu'on touche un peu au dynamisme.
M'enfin, allons voir ailleurs si qqchose de plus constructif est sorti de ce thread.
-- laurent
Laurent vilday
Voila, imo, une raison justifiant l'ajout dynamique a la suite d'un <textarea> ou <input type=text>.
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 ?
Pour plusieurs raisons, tout d'abord parce que on est sur fclj et pas sur le support de prototype, jQuery, YUI, Ext, et autres mooTools.
Ensuite parce qu'ils manquent trop d'informations pour déterminer le besoin réel. Et donc autant faire du JS de base plus facile à comprendre, comme ça l'OP pourra éventuellement en faire qqchose.
Egalement parce que j'ai essayé et abandonné toutes les librairies plus ou moins "hype" qui sont passées, ça m'obligerai à trop de modifications dans mon travail, et surtout ça me ferait perdre un temps fou si je devais reformer mon équipe de devs à chaque fois qu'une nouvelle librairie plus "mode" apparait.
Il ne faut pas oublier que JS est encore et toujours un langage très très (très) mal compris. Hors je suis persuadé que d'utiliser une des librairies citées (prototype, jquery, etc) nuit à l'apprentissage du langage.
Version prototype : $($('myDiv').parentNode).hide()
Version JS : function hide(e) { ... } var elt = document.getElementById('myDiv'); hide(elt.parentNode);
Certes la version de prototype (grrr et quelle idée ce nom, c'est confusing à mort) est plus concise. Mais la version JS est plus compréhensible pour le comment des mortels.
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 ?
Ca dépend du contexte. Sur une page internet ou il y a 3 ou 4 champs qui se battent en duel, ça pourrait suffire.
Par contre pour une "application web" qui doit maintenir une cohérence graphique au fil des interfaces, ça peut alourdir l'UI.
Tout n'est que question de contexte.
-- laurent
Voila, imo, une raison justifiant l'ajout dynamique a la suite d'un
<textarea> ou <input type=text>.
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 ?
Pour plusieurs raisons, tout d'abord parce que on est sur fclj et pas
sur le support de prototype, jQuery, YUI, Ext, et autres mooTools.
Ensuite parce qu'ils manquent trop d'informations pour déterminer le
besoin réel. Et donc autant faire du JS de base plus facile à
comprendre, comme ça l'OP pourra éventuellement en faire qqchose.
Egalement parce que j'ai essayé et abandonné toutes les librairies plus
ou moins "hype" qui sont passées, ça m'obligerai à trop de modifications
dans mon travail, et surtout ça me ferait perdre un temps fou si je
devais reformer mon équipe de devs à chaque fois qu'une nouvelle
librairie plus "mode" apparait.
Il ne faut pas oublier que JS est encore et toujours un langage très
très (très) mal compris. Hors je suis persuadé que d'utiliser une des
librairies citées (prototype, jquery, etc) nuit à l'apprentissage du
langage.
Version prototype :
$($('myDiv').parentNode).hide()
Version JS :
function hide(e) { ... }
var elt = document.getElementById('myDiv');
hide(elt.parentNode);
Certes la version de prototype (grrr et quelle idée ce nom, c'est
confusing à mort) est plus concise. Mais la version JS est plus
compréhensible pour le comment des mortels.
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 ?
Ca dépend du contexte. Sur une page internet ou il y a 3 ou 4 champs qui
se battent en duel, ça pourrait suffire.
Par contre pour une "application web" qui doit maintenir une cohérence
graphique au fil des interfaces, ça peut alourdir l'UI.
Voila, imo, une raison justifiant l'ajout dynamique a la suite d'un <textarea> ou <input type=text>.
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 ?
Pour plusieurs raisons, tout d'abord parce que on est sur fclj et pas sur le support de prototype, jQuery, YUI, Ext, et autres mooTools.
Ensuite parce qu'ils manquent trop d'informations pour déterminer le besoin réel. Et donc autant faire du JS de base plus facile à comprendre, comme ça l'OP pourra éventuellement en faire qqchose.
Egalement parce que j'ai essayé et abandonné toutes les librairies plus ou moins "hype" qui sont passées, ça m'obligerai à trop de modifications dans mon travail, et surtout ça me ferait perdre un temps fou si je devais reformer mon équipe de devs à chaque fois qu'une nouvelle librairie plus "mode" apparait.
Il ne faut pas oublier que JS est encore et toujours un langage très très (très) mal compris. Hors je suis persuadé que d'utiliser une des librairies citées (prototype, jquery, etc) nuit à l'apprentissage du langage.
Version prototype : $($('myDiv').parentNode).hide()
Version JS : function hide(e) { ... } var elt = document.getElementById('myDiv'); hide(elt.parentNode);
Certes la version de prototype (grrr et quelle idée ce nom, c'est confusing à mort) est plus concise. Mais la version JS est plus compréhensible pour le comment des mortels.
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 ?
Ca dépend du contexte. Sur une page internet ou il y a 3 ou 4 champs qui se battent en duel, ça pourrait suffire.
Par contre pour une "application web" qui doit maintenir une cohérence graphique au fil des interfaces, ça peut alourdir l'UI.
Tout n'est que question de contexte.
-- laurent
filh
Laurent vilday wrote:
Egalement parce que j'ai essayé et abandonné toutes les librairies plus ou moins "hype" qui sont passées, ça m'obligerai à trop de modifications dans mon travail, et surtout ça me ferait perdre un temps fou si je devais reformer mon équipe de devs à chaque fois qu'une nouvelle librairie plus "mode" apparait.
Ah ben changer sans arrêt n'est pas une bonne solution. Mais ne jamais changer :)
Il ne faut pas oublier que JS est encore et toujours un langage très très (très) mal compris. Hors je suis persuadé que d'utiliser une des librairies citées (prototype, jquery, etc) nuit à l'apprentissage du langage.
Well... ce qui fait chier c'est d'avoir des programmeurs qui ne possèdent pas les principes du langage hors du langage :)
Chais pas moi donnez leur des cours de Scheme :)
Version prototype : $($('myDiv').parentNode).hide()
Version JS : function hide(e) { ... } var elt = document.getElementById('myDiv'); hide(elt.parentNode);
Certes la version de prototype (grrr et quelle idée ce nom, c'est confusing à mort) est plus concise. Mais la version JS est plus compréhensible pour le comment des mortels.
J'avoue que Jquery. :) Le $ est un peu limite.
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Laurent vilday <mokhet@mokhet.com> wrote:
Egalement parce que j'ai essayé et abandonné toutes les librairies plus
ou moins "hype" qui sont passées, ça m'obligerai à trop de modifications
dans mon travail, et surtout ça me ferait perdre un temps fou si je
devais reformer mon équipe de devs à chaque fois qu'une nouvelle
librairie plus "mode" apparait.
Ah ben changer sans arrêt n'est pas une bonne solution. Mais ne jamais
changer :)
Il ne faut pas oublier que JS est encore et toujours un langage très
très (très) mal compris. Hors je suis persuadé que d'utiliser une des
librairies citées (prototype, jquery, etc) nuit à l'apprentissage du
langage.
Well... ce qui fait chier c'est d'avoir des programmeurs qui ne
possèdent pas les principes du langage hors du langage :)
Chais pas moi donnez leur des cours de Scheme :)
Version prototype :
$($('myDiv').parentNode).hide()
Version JS :
function hide(e) { ... }
var elt = document.getElementById('myDiv');
hide(elt.parentNode);
Certes la version de prototype (grrr et quelle idée ce nom, c'est
confusing à mort) est plus concise. Mais la version JS est plus
compréhensible pour le comment des mortels.
J'avoue que Jquery. :)
Le $ est un peu limite.
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
Egalement parce que j'ai essayé et abandonné toutes les librairies plus ou moins "hype" qui sont passées, ça m'obligerai à trop de modifications dans mon travail, et surtout ça me ferait perdre un temps fou si je devais reformer mon équipe de devs à chaque fois qu'une nouvelle librairie plus "mode" apparait.
Ah ben changer sans arrêt n'est pas une bonne solution. Mais ne jamais changer :)
Il ne faut pas oublier que JS est encore et toujours un langage très très (très) mal compris. Hors je suis persuadé que d'utiliser une des librairies citées (prototype, jquery, etc) nuit à l'apprentissage du langage.
Well... ce qui fait chier c'est d'avoir des programmeurs qui ne possèdent pas les principes du langage hors du langage :)
Chais pas moi donnez leur des cours de Scheme :)
Version prototype : $($('myDiv').parentNode).hide()
Version JS : function hide(e) { ... } var elt = document.getElementById('myDiv'); hide(elt.parentNode);
Certes la version de prototype (grrr et quelle idée ce nom, c'est confusing à mort) est plus concise. Mais la version JS est plus compréhensible pour le comment des mortels.
J'avoue que Jquery. :) Le $ est un peu limite.
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
