Reprise du message précédent :

Ca change rien t'as pas besoin de bindWithEvent, bind suffira

Bah si je fais un bind(this, $('elm')) ... ça me dit que item est non défini.
 
Où alors je ne comprends pas ce que tu veux dire ...

Nan, ce que je veux dire t'es pas censé/obliger d'appeler $() à tout bout de champs, c'est pas jQuery
 

var myClass = new Class({
    Implements: Options,
    options: {
        width: 42
    },
    initialize: function(options){
        this.setOptions(options);
        this.element = $('elm');
 
        this.element.addEvent('mouseover', function(evt){
            this.element.setStyle('width', this.options.width);
        }.bind(this));
    }
});

Ça ne marche pas.
 
Le addEvent est dans un each, j'effectue un traitement sur chaque élément, puis je leur applique le addEvent.
 
Donc en stockant l'élément courant, et en utilisant cet élément dans le addEvent, quelque soit l'élément sur lequel je déclenche l'event, il s'appliquera au dernier qui a été enregistré (c'est peut être pas clair )

Oui je comprends. Dans ce cas il faut faire autrement (c'est tout l'intérêt de forEach qui bind la fonction executée à l'élement pointé dans la boucle)
 
Si tu itères sur les élements et que tu effectues un traitement propre à chaque element pour un addEvent :
 

var MyClass = new Class({
    Implements: Options,
    options: {
        width: 42
    },
    initialize: function(options){
        this.setOptions(options);
        this.elements = $$('.elm');
 
        this.elements.forEach(function(element) {
                //Processing
                element.addEvent('mouseover', function(evt){
                    evt = new Event(evt);
                    element.setStyle('width', this.options.width);
                }.bind(this));
        },this);
    }
});

Pour un addEvent sur un set d'élements (ici tu dois utiliser bindWithEvent si tu veux conserver l'evenement) :

var MyClass = new Class({
    Implements: Options,
    options: {
        width: 42
    },
    initialize: function(options){
        this.setOptions(options);
        this.elements = $$('.elm');
 
        this.elements.addEvent('mouseover', function(evt){
           element.setStyle('width', this.options.width);
        }.bindWithEvent(this));
    }
});

 
Ps : Un autre truc, je te conseillerais de nommer tes classes avec une Majuscule au début, histoire de rester l'idiome de Mootools

Deux bonnes idées pour cacher des adresses mail des spammers avec CSS. J'aime bien le second, le premier faut voir s'il passe sur tous les browsers.
On oublie

C'est moi ou gotapi.com est tout mort ?

C'est une bonne idée mais un peu foireuse, vu que le copier coller va te prendre la chaine de caractère à l'envers, ou le null dans ton mail

Ah putain ouais Pour le null, j'aurais dû y penser mais pour le truc inversé c'est un peu con comme comportement du browser, non ?

FlorentP

Je trouve pas, l'affichage à l'envers c'est de la pure mis en forme, ça n'a pas d'impact sur la chaîne elle même...
 
Si tu collais cette chaîne dans un environnement avec la même mise en forme, tu t'attendrais à ce qu'elle apparaisse pareil que lors de a copie, non ?
Ex : affichage "abc" (style : reverse).
copie : "cba"
collage dans un endroit avec style reverse : affichage "abc".
 
Alors que si tu avais copier "abc", ton collage aurait donné logiquement : "cba" à l'affichage. Ce qui n'est pas très cohérent

Pas forcément. Prenons IE (), tu fais copier/coller dans Word/Outlook/un truc qui accepte les copier/coller plus riches que du texte de base d'un texte contenant de la mise en forme : gras, police plus grande ou différente, couleur rouge, etc... Bin dans ton appli cible, tu auras la même mise en forme. Par contre, il garde pas la direction du texte
 
Donc ouais, je peux comprendre ce que tu exlpiques mais c'est pas cohérent en fonction du browser. De plus, l'utilisateur au final va voir son texte affiché dans un sens dans le browser mais pas dans l'appli cible. Ch'ais pas, ça me dérange un peu quelque part

"qui accepte les copier/coller plus riches que du texte"
Oué tu copie le style en même temps que la chaîne de caractère... peut être que IE bloque ce style là pour éviter de copier/coller des trucs erronnés sans que tu t'en rende compte ? (ou simplement parcequ'il gère pas ce genre de mise en forme ? )

Mais de toute façon, j'ai jamais encore vu un logiciel de mail gérer des style dans les adresses de destinataire, et encore moins un protocole de communication gérer les styles dans les packets pour savoir si le destinatire est à lire aà l'endroit ou a l'envers

En même temps, ça fait maintenant quelques années qu'aucune adresse email publiée sur Internet n'est copiable directement ! Entre les images pur l'@, et les remplacements par AT, DOT, & Co, on est obligé, à chaque fois, de ré-écrire l'adresse. Donc je ne vois pas en quoi ces solutions, qui semblent efficaces, sont plus gênantes que d'autres !

Souvent les url sont aussi diffusée directement, et un copier coller suffit.
Généralement, les mails que les gens récupère proviennent aussi de sources "privée" et un copier coller suffit.
Et quand il y a un remplacement clair & évident (genre toto AT pouet DOT com), la personne sait en faisant sont copier/coller qu'il va falloir qu'elle retouche l'adresse.
Alors que si tu copie "toto@pouet.com" et qu'au copier tu as un "toto@nullpouet.com", je suis sur que plus de la moitié des gens ne vont pas s'en rendre compte...

(sur mon site web, a un moment je remplaçais le "@" par un image en rouge de l'arobase, avec un alt=" A ". Comme ça les genre copiaient "toto A pouet.com", ça me semblait clair. Mais non, j'ai eu très rapidement beaucoup de retour me demandant pourquoi les adresses mails étaient foirées...)

Parce qu'avec des AT DOT, on sait clairement qu'on va devoir réécrire l'adresse (et ce qu'on doit réécrire, le @ et le .).
Avec les null et le reverse, rien n'indique qu'on va devoir modifier l'adresse, et une étourderie (ou mm pas) peut vite amener à garder le null. Et pour le reverse j'ai même pas besoin d'argumenter je crois
--
burn burn yeah yar gonna burn

Il faut adapter ! Avec le NULL par exemple, on peut utiliser le même principe en mettant
truc@SUPPRIMER_TOUT_LE_TEXTE_ENTRE_L'AROBASE_ET_MUCHE_muche.com
 
(NB: ce n'est qu'un exemple )

Ouai mais nan, faut pas.
Soit tu donne l'info AVANT la copie, qu'il va falloir faire un traitement sur la chaine, soit tu fournit la chaine "clean" à l'utilisateur, plutot que faire un truc un peu dégeux
Les gens ils s'amusent pas à regarder en détail ce qu'ils font, faire ça c'est chercher les problèmes

Et c'est dur à capter pour l'utilisateur, j'ai un virus dans mon copier-coller

Ce n'était qu'un exemple juste pour illustrer "Il faut adapter" !
Moi, perso, je n'utiliserais pas ce genre de méthode
 

Remarque très pertinente

http://ejohn.org/blog/dom-documentfragments/

Gains partout, entre 2x et 3x

Des tests ont été faits sur jquery: http://dev.rubyonrails.org/ticket/11468#comment:5

=> pas vraiment de différence pour Opera 9.2, ff2 et ff3, diminue pas mal les perfs de Safari 3.1, légère amélioration pour Opera 9.5... runtime du bench divisé par 60 sous IE6 et 20 sous IE7

je note, j'ai justement un problème de ce type a résoudre ( génération d'un paquet de noeud )

Lazy loading pinaise

 
c'est justement pour acceler du lazy loading    
je suis , dans le pire des cas sous IE a une seconde, ce qui est un peu long pour une action a faire répétitivement

1 seconde? Quelle taille font tes chunks?

 
dans le pire des cas ( une GED qui contient pas mal de doc, avec un profil qui contient pas mal de monde ) , je charge un tableau  d'une cinquantaine de ligne avec une dizaine de colonnes  
 
sur les personnes qui ont de vielles machines ( on a encore quelque petits p4 ) c'est loin d'etre immédiat , surtout en ajoutant le delai incompressible de la requete

Il a des différences notables entre le Swiff du dernier Mootools et Swfobject ?

C'est peuplé via ajax? C'est obligatoire? Donc la tu n'as pas de chunk? J'entends par là que si tu veux grandement améliorer la vitesse de traitement tu peux casser la génération par morceaux de 10 espacés de 100ms.
 
L'autre solution, un peu plus complexe mais beaucoup plus élégante, c'est de charger les informations au scroll (a partir d'un dataset déjà traitement, ce qui prends du temps ce sont les DOM hits).
 

L'API n'a rien à voir.

1- oui
2- disons que pour l'instant c'est ce que j'ai trouvé de moins pire  
3- je testerai  
 
pour l'autre solution, je verrai , mais je me sens pas trop le courage

http://www.toosweettobesour.com/20 [...] -closures/ Même les closures, ils arrivent à les rendre dégueulasses, illisibles et imprédictible

J'ai failli répondre "regarde les propals java" avant de cliquer, mais en fait... t'as raison, ils font encore pire en php

 
En fait c'est juste le ticket d'entree qui est un peu bas
Je me demande comment il gere son deploiement le mauvais developpeur

T'as vu la tronche du source PHP?

Faut pas parler de ça malheureux, maintenant florentG va débarquer nous dire que c'est fait exprès pour qu'il soit super super super rapide, et que tout est parfaitement normal

 
Il peut pas il est au centre aéré la

oh merde

c'est fait exprès pour qu'il soit super super super rapide, tout est parfaitement normal

Fixed

Pk impredictible ?
C'est pas le principe, que d'avoir la valeur de leur variable "global" au moment de la définition de la fonction et qu'elle n'évolue pas ?

Sûrement pas non