Reprise du message précédent :
 
 
Nan, c'est plus complexe que ça mon identification, il y a dialogue direct entre mon serveur et le serveur d'auth.
Mais si je me connecte à la main dans mon navigateur et que je récupère l'id de session mon appli ne redemande pas l'auth de quelqu'un qui est considéré déjà connecté, donc ça doit être jouable...à tester.

merci je vais y jeter un oeil

Dites, y'en a qu'on déjà joué avec "Adobe Air" ou pas encore?  
Si oui c'est comment?

Yavait pas un topic dédié aux design patterns a un moment ?

En attendant je pose ma question, ce sera ptet mm mieux ici : on dit souvent Singleton blabla pour les calsses d'accès à la BDD, pourquoi ne pas la faire en static pur ? Quels inconvénients ?
 
En tout cas je vois les avantages :  
 
DB::getInstance()->fetchAll('SELECT hey FROM wow');
DB::fetchAll('SELECT hey FROM wow');

 
où ça un avantage?

15 lettres à chaque requetes

ok, lol.

Sinon, les inconvénients ?

 
n'avoir aucun avantage?

Tu les ferais comment tes requêtes préparées, avec ça?

J'en fais pas  
Mais du peu que j'en connaisse, je vois pas mal de solutions, en singleton tu fais comment ?

ok, lol.

J'ai pas de singleton.
Et j'ai une classe query + une classe qui fait l'interface avec la base.

...et ta solution c'est aussi un singleton, mais avec uniquement des méthodes statiques, ou alors j'ai pas compris ce que tu voulais faire.

héhé

Donc t'as tes classes instanciées dans des variables globales avec des "global" partout ?

Pas un singleton classique, en tout cas.

theredled, tout est statique dans ma classe DB de mon côté.
 
J'ai juste à faire DB::getRow('SELECT foo FROM bar WHERE baz = "qux"');
 
Au moment de la requête on regarde si on a déjà une instance stockée ou non, si oui on l'utilise, si non on la créée.
 
En gros l'étape "DB::getInstance()" est réalisée par la classe elle même, et non par l'utilisateur

 
Non.
 

 
Si. Un singleton c'est une classe qui ne peut être instanciée qu'une fois, après tu fais ce que tu veux.

'tain, c'est l'horreur

Pourquoi  

ben à la base quand tu fais colllection.each, tu veux juste itérer sur une collection sans faire apparaître l'index. Mais comme l'implémentation de each est par une fonction et que les fonctions ferment pas sur le this, si tu utilises this dans une boucle, il faut utiliser bind() sinon, c'est pas la peine.
 
Mais la bonne nouvelle c'est que si tu oublie cette règle pourtant simple (), parce que tu étais concentré par exemple sur les différentes implémentations entre navigateurs du truc que tu manipules tu le sauras pas avant l'exécution.
 
En gros tout ce qui concerne la manipulation de fonctions dans ce langage devient l'horreur si tu manipules des états un peu encapsulés dans des objets. Bref, c'est hautement irrégulier.

Voilà, pareil, sauf que la préservation de l'instance unique n'est qu'au niveau du connect(). Donc j'ai même pas de getInstance() (je pourrais le faire si je voulais faire des requetes préparées etc, cela dit) (ou si je voulais virer le connect() ) (edit : c'est fait )

Bah c'est bien, ça doit être vachement bien, alors

Ya des lettres que tu comprends pas dans le mot "classique"

 
Oui.
J'utilise des connexions persistantes, et l'instanciation de l'objet qui la contient est négligeable.
 

 
Non. Par contre je suis pas sûr que tu saisisses le fait que tout passer en statique n'apporte rien du tout.

C'est super.

Je t'ai dit que le this en JS c'était une horreur

Bon, je laisse tomber. De toute manière ça devrait déjà pas être un singleton, donc bon...

Singleton, ça correspond à un design pattern précis, pas seulement à un but abstrait.
 
Donc mon truc, c'est pas un Singleton proprement dit, je maintiens.

T'as lu la doc de la méthode each de Prototype et notamment le second argument ? Ca te fera le bind() tout seul

$('tonTableau').observe('click', function(evt) {
    var element = evt.element();
    if (element.tagName == 'TR') {
        // ton code
    }
});

je reviens à la charge, c'est quoi l'avantage comparatif de ça avec un onclick ? est-ce que dans un onclick je peux récupérer l'objet event evoyé ? (j'ai vaguement googlé, mais ça manque d'expertise solide). C'est spécifié où les onclick etc. ?

Tu parles d'un onclick DOM classique ou d'un onclick prototype?

Même question que Masklinn
 

heu <lol onclick="monjs()"></lol>

Alors oui il est possible de récupérer l'objet event (enfin pas comme ça, mais quand tu bind ton event programmatiquement ça l'est), par contre:

• Cet objet event est récupéré de manière complètement différente (passé en paramètre au callback pour les events DOM, accessible via window.event pour MSIE) et est lui même très différent entre MSIE et tout le reste (cf http://www.quirksmode.org/dom/w3c_events.html pour les précisions, entre autres c'est assez lourd pour annuler proprement les actions par défaut)
• Binder des events directement avec des lambdas a tendance à créer des références circulaires entre le JS et le DOM, donc sous MSIE entre le moteur JScript et le moteur COM => epic fail inc sous MSIE
• Tu ne peux (si je me souviens bien) pas te créer d'events custom

Normalement, les frameworks JS résolvent le premier en créant un event surcouche uniforme entre tous les browsers, le second en cassant proprement les références circulaires à l'unload de la page, et permettent parfois de créer des events custom en cas de besoin (en tout cas Mootools le permet)

Et c'est sans parler du problème du this, que tu sais jamais sur quoi il va être bindé (mais c'est de toute façon jamais sur le bon truc)

Prototype permet de faire des event custom aussi
 
Et surtout t'as oublié le point le + important à mon sens, c'est que le fait de ne plus utiliser d'event inline permet de bien séparer les couches et de faire du JS unobtrusive.

Prière de relire la première ligne.

Il n'y a pas besoin d'utiliser un framework pour binder des évènements programmatiquement.

j'ai un peu de mal à saisir le concept, parce que sans JS -> pas de site. donc la séparation elle est morte non ?

Ben pas nécessairement, sur ton site par exemple il y a pas grand chose qui requière explicitement du JS, voire rien en fait.

justement, là ça va changer, quand je vais mettre les lignes du tableau intégralement clickables (en JS donc), ça va être exactement l'inverse (pas de click-> pas d'entraînements -> pas de site)

ben un des éléments de ton tableau se doit alors d'etre clicable
genre tu fous un lien sur le contenu de ta premiere cellule

Rendre tout le tableau cliquable en JS ne te force pas à retirer les liens existants

'tain je suis rincé du cerveau là.

vous voyez le bug ?