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

ASM a écrit :
> rico a écrit :
(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.

Guy a écrit :
> 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>
> rien à voir avec la demande "ajouter du HTML"

Pardon ?

elt.parentNode.insertBefore(container, elt.nextSibling);

C'est pas "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

Guy a écrit :
> 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>
> rien à voir avec la demande "ajouter du HTML"

Pardon ?

elt.parentNode.insertBefore(container, elt.nextSibling);

C'est pas "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

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

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

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

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