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