Reprise du message précédent :
IWH 1111 \o/

http://caniuse.com/#search=eventSource
 
'tin il y a déjà masse de support pour EventSource en fait

OSEF, dès que FF6 est sorti (q3 normalement) c'est 60% de support

ma bite ?

J'ai envi de créer un projet de site communautaire, évidemment je suis loin d'être un grand codeur... ça sera l'occasion de m'y mettre vous me conseillez quoi comme base ? CodeIgniter ?

Ya un topic pour les CMS d'e-commerce ?

Quelqu'un a déja utilisé Prestashop ?

1/ Créer un site communautaire n'est pas une petite chose  
2/ Il y a déjà des outils complets qui existent (vbulletin, invision, etc)
 
Si tu es loin d'être un grand codeur, il y a des choses plus accessibles.
 
Après CodeIgniter est une bonne base en PHP.

 
Déjà utilisé.  
C'est plutôt pas mal et propre, même si c'est quand même une petite usine à gaz. Mais y a une bonne communauté et les outils sont clairs. C'est un peu ce qu'il y a de mieux sur le marché en ce moment en CMS E-commerce. Et y a un eco-système assez intéressant également avec bcp de plugins payants mais efficaces.

Il ne faut pas regarde le coté "usine à gaz" mais plutôt le coté : "ça répond à tes besoins et est maintenu par une communauté"

J'ai déja fait tout le site en fait
J'ai plutôt la vision inverse, c'est pas une usine à gaz pour ce que c'est, mais c'est super mal foutu niveau réutilisation (genre, après skinnage HTML le panier Ajax est inutilisable sans modifier le JS) et moche graphiquement de base.

Mon problème c'est les module de banque, ça me fait chier de payer 250 € (SPPlus) pour payer un truc que quelqu'un va installer à ma place ou dont je vais devoir quand même compiler des trucs... je suis un peu dégouté, je pensais que les modules de paiement de base était gratuits et bien faits. Peu de retours en plus.

Je regrette presque Magento

Et je sais pas quoi faire. Ya des devs qui vendent des modules moins chers... Ca me fait ultra chier si j'achète un truc qui marche qu'à moitié et je perd du temps au final.

dites, j'ai vraiment l'impression que le padding est à l'extérieur de width et height, je me trompe ?
j'ai 15px de padding partout, width:331px;height:172px; et chrome me donne 363px x 204px comme taille extérieure de la box.

oui le padding est en plus.

(et oui c'est naze)

Non, c'est bien ce qui se passe dans le box model W3C. Pour une fois, c'est MS qui avait raison...

Il y a une propriété CSS3 qui s'appelle Box Sizing qui permet de switcher entre IE (dans lequel width inclue border et padding) et W3C (dans lequel padding et border sont en plus de width), et c'est supporté dans tous les navigateurs sauf IE7

Truc de base en CSS,  en mode W3C
http://www-lih.univ-lehavre.fr/~fo [...] php?page=3
IE6 en mode quirks (pas de doctype HTML4 ou xhtml1...) ne prends pas en compte les padding ni borders
 
En revanche pour ce qui est des navigateurs récents, on a la possibilité d'utiliser le box-sizing, mais chaud http://css-tricks.com/box-sizing/

Firefox 3+, Safari 3.1+, Chrome 8+, Opera 10.5+, ça commence à faire pas récent quand même
 
Il y a juste MSIE, pour lequel ce n'est supporté qu'à partir d'IE8.

ok, merci les gars.

Quand je parle de récent, je parle de navigateur autre que IE8-
 
Bon et sinon tu tombes bien , et si Shinuza et/ou 0x90 sont levés, je cherche un système de classe comme mootools, avec son style d'écriture, qui permet de faire un "implements" avec gestions de Options et Events
 
Mais ce système de classe doit aussi gérer le merge des options et même des autres propriétés  entre classe mère et une classe fille (celle qui hérite).
Exemple :  

Et ce systeme de classe doit aussi gérer correctement les problèmes des références sur le prototype entre les instances.
 
 
Actuellement on travaille (enfin thib) sur un équivalent basé sur Base.js(), mais transformé pour être proche de l'écriture de mootools, on gère aussi implements, extends et Options et Events. Mais la gestion des références sur le prototype ainsi que le deepcopy de options ne sont pas au point.  
 
J'ai un besoin assez urgent. Pour le moment, pour le projet j'ai collé mootools serveur, mais il tape trop sur les prototype des types primitifs, s'il y a Prototype qui traine dans le coin sur un site et que je colle mon bordel je ne suis pas sur que ça marche super derrière.
Je peux rendre mootools serveur en mode "standalone" pour n'avoir que Class à utiliser mais je ne sais pas si ça me prendra une blinde de temps  

Du plus au moins complèt.
 
http://jsclass.jcoglan.com/
 
http://classy.pocoo.org/
 
http://www.dustindiaz.com/klass
 
C'est pour faire quoi ton truc?

Mon projet sur lequel je suis ?
On génère un formulaire depuis un XML qui contient pleins de fonctionnalités comme la validation, comportements (show/hide en fonction d'une valeur de champ et d'un champ), + composants avancés qui viennent se greffer sur le formulaire ou peuvent être autonomes.

Enfin bref, derrière tout ça, ya un paquet de classes et pas mal d'héritage, et les composant communiquent entre eux à coup d'events, ça sert bien

J'ai oublié de dire que je suis allé faire un tour sur  http://microjs.com/#class et aucune des libs proposées ne me convenait, elles sont toutes incomplètes comparé à mootools

en fait j'aurai du partir sur du JSClass et creer une classe de départ qui aurait possédé ou implémenté par défaut Options et Events et après yavait plus qu'à faire étendre les autres. Arf quelle quiche je suis

Attention à ne pas écrire des trucs du genre:

var instance1 = new class1();
var instance2 = new class2();
 
instance1.addEvent('new object', function(obj) {
    instance2.register(obj);
});

var class1 = new Class({
    initialize: function() {
        someobject.addEvent('foo', function() {
            // Do something
        })        
    } 
});

La plupart des trucs qui sont là dedans à part Classy sont complètement à chier. Soit incomplètes, soit pas du tout Javascripty, soit elles pompent des trucs de C++ tout moches. Si t'as besoin de Mootools prends Mootools, le seul truc c'est qu'après t'es tenté d'utiliser Core + More, donc à voir selon ton usage.
 
Sur ce genre de projet t'as besoin de quoi gérer les requêtes, de quoi manipuler des collections, de quoi manipuler le dom, d'objets avec un comportement donné. En gros de Backbone/Spine quoi

Sslac.Class("Your.Class" ).Extends("Extends.Object" ).Implements("Implements.Object" )
.Constructor(function Constructor(paramOne, paramTwo) {
 
})
.Method("methodName", function methodName(paramOne, paramTwo) {
 
});
// ...
var foo = new Your.Class("one", "two" );

Non mais franchement

var instance1 = new class1();
var instance2 = new class2();
 
instance1.addEvent('new object', function(obj) {
    instance2.register(obj);
});

var class1 = new Class({
    initialize: function() {
        someobject.addEvent('foo', function() {
            // Do something
        })        
    } 
});

Ce projet doit être au minimum indépendant, il y a du jquery derriere mais pour le reste on doit eviter au maximum de trop utiliser de gros framework ou des trucs qui laissent des variables un peu partout. Surtout qu'il doit pouvoir être utilisé sur n'importe quel site. Et concernant les events on est bien d'accord sur le principe :  
 
 

PArce que oui tes exemples font peur

Sslac.Class("Your.Class" ).Extends("Extends.Object" ).Implements("Implements.Object" )
.Constructor(function Constructor(paramOne, paramTwo) {
 
})
.Method("methodName", function methodName(paramOne, paramTwo) {
 
});
// ...
var foo = new Your.Class("one", "two" );

Quand je regarde le code de certaines, ça me faire peur, mais alors peur :s

Ça c'est pas un soucis :

var MonProjet = {
    '_' : _.noConflict(),
    '$': $._noConflict()
};

(function($) {
    alert($(document).jquery);
})(MonProjet.$);

Comment écoutes-tu l'event "validate"?

c'est le onValidate, sous mootools ça te fait automatiquement un addEvent('validate').
 
L'objet qui instancie FooClass ecoute via onValidate. On est d'accord sur le principe ou alors j'ai mal expliqué ?

http://en.wikipedia.org/wiki/Inter [...] _model_bug
En résumé, tu te mets en mode standard W3C en mettant le doctype kivabien dans ton doc et t'auras rien à faire dans ta CSS à part mettre les bonnes valeurs qui seront du coup valables partout.

C'est le premier truc qu'on fait normalement de configurer le bon box model avec le doctype

Bof autant mettre le bon doctype dès le début pour pas être emmerdé

T'es bredin aujourd'hui? Il décrit précisément le box model W3C, qui le fait chier parce qu'il est débile (le box model, pas nraynaud).

You missed the point: le box model W3C est à chier, et tu peux pas le changer avec un doctype. Par contre tu peux le changer via CSS

Ça change rien
 

var fooObject = new FooClass({
    'onValidate': anotherObject.doSomething
});

 
et
 

var fooObject = new FooClass;
fooObject.addEvent('validate', anotherObject.doSomething);

 
C'est totalement équivalent. Tu fais explicitement référence à ton objet émetteur d'une manière ou d'une autre.
Il faut utiliser objet abstrait qui ne connait rien de l'implémentation, un bus de messages :

MonProjet.dispatcher.fireEvent('validate', function() {
 
});
 
MonProjet.dispatcher.trigger('validate', function() {
 
});

MonProjet.dispatcher = new Events; // Mootools
MonProjet.dispatcher = document; // jQuery

 
du coup

var anotherObject = AnotherClass({
    initialize: function() {
        MonProjet.dispatcher.bind('validate', this.doSomething);
    }
});

 
si FooClass n'existe pas RAF, ça change rien à ton code. Le seul "downside" c'est qu'il faut namespacer les events, mais bon avec une bonne doc...

Là tu me parles d'un notifier global à l'application.
Moi je te parle de communication entre 2 objets entre eux qui ne se connaissent pas réellement. L'un l'instancie (objet du formulaire qui lance un composant métier avancé) et attend une réponse, l'autre envoi la réponse par event (genre l'utilisateur clique sur le bouton "valider" du composant métier.

Je dois peut-être mal m'expliquer ou alors on n'a pas la même notion

Petit coup de fatigue j'avais mal lu son post
Je pensais qu'il avait un souci de rendu cross nav à cause du box model.
Je vais me coucher

Excuse acceptée mais n'y revenez pas

Zavez vu scheme.org ici? C'est autre chose qu'une refonte des microformats.org?

L'un n'empêche pas l'autre. Au contraire, utiliser un event broadcaster global permet de découpler d'avantage tes widgets/classes.

L'auto-complétion foireuse de PHPStorm

Heureusement que j'ai découvert Pomme-N pour rechercher une classe

Heu Heu, l'autocomplétion de phpstorm est celle qui déboite le plus de poneys par rapport à netbeans, aptana, ou eclipse.  
 
Et puis si tu JSdoc ou Phpdoc bien ton code tu n'aurais pas de problème de complétion
 
Donc je ne vois pas ton problème.
Et sinon :  
Pour rechercher une classe c'est POMME+N,  
Et pour rechercher une ressource, c'est POMME+SHIFT+N, c'est plus bourrin là

Bah c'est bien simple, je suis sous Symfony qui est très bien PHPdocé, et il ne reconnait pas certaines propriétés et méthodes héritées, comme s'il ne trouvait pas un parent. Alors qu'un pomme-clic à répétition arrive bien au bon parent.

Et aussi, quand on pomme-clic sur le nom d'une classe, il va pas dedans mais dans son constructeur (qui peut etre ailleurs donc). C'est pas le plus con, mais quand même c'est chiant.

Et quand on crée une classe, ya rien pour mettre automatiquement les méthodes abstraites à traiter, avec les bonnes signatures etc... tu te retrouves à chercher la classe d'origine et copier coller la signature.

Par ex.

1111 IWH

hoho