Zend FR

C'est bien ce que je dis.
Si vous êtes tous fan de js à faire votre sie en 50% Javascript, c'est sur que c'est pas avec ZendX que vous allez faire !

Et puis si moi j'ai besoin de 4 lignes pour faire un datepicker, je vois pas qui ou quoi m'en empêche de le faire avec le helper plutot que d'utiliser un fichier indépendant.

Vous me faites rire a parlé de performance et de codé un site en Javascript !!
Vous mélangez vraiment tout.

On a pas tous les même but, la même façon de coder et les mêmes attentes... faudrait pas l'oublier.

De plus, on passe carrément hors-sujet la..

Et puis si moi j'ai besoin de 4 lignes pour faire un datepicker, je vois pas qui ou quoi m'en empêche de le faire avec le helper plutot que d'utiliser un fichier indépendant.

Personne n'a dit le contraire. C'est une discussion ouverte sur ce que peut nous apporter tel ou tel solution.

Vous me faites rire a parlé de performance et de codé un site en Javascript !!
Vous mélangez vraiment tout.

Qui à parlé de coder un site en javascript?
Sekaijin nous rapporte gentillement son expérience sur une Web Application.
Je ne vois pas ce qui est mélangé.
(Un site contenant bcp de javascript qui ne serait pas mis en cache peut ramer à mort si le Js est chargé dans le head de la page. Je parle en connaissance de cause. Après ça dépend aussi du navigateur...)

On a pas tous les même but, la même façon de coder et les mêmes attentes... faudrait pas l'oublier.

Presonne n'a oublié ça, mais en général, lorsque l'on utilise le ZF, c'est pas pour faire un mini site de 4 pages avec un datepicker. Mais évidemment qu'un gros site (ou pas) avec très peu de js peut se satisfaire de Zend_Dojo ou encore de ZendX_JQuery. Et heureusement car sinon ça aurait était développé pour rien.

Je pense qu'on a fait le tour là

simple avis
pour avoir complétement boudé Jquery en faveur de dojo (ZEND A CHOISIS DOJO = DOJO céybien) et avoir passé un bon mois a...ahm.. utilisé ce framework un accident a fait que j'ai utilisé jquery pour une bricole
depuis "jquery in Action" trône sur mon bureau, des tonnes de plugins jquery trainent partout dans mes répertoires et je suis complétement accro a ce truc.
ma concolusion ( actuelle ) est trés simple comparé à Jquery, DOJO est une HORREURE ABSOLUE.
Good luck à toi, Salut

pour en revenir au fond du sujet DOJO VS JQuery

je trouve que jQuery est parfaitement adapté pour de "petits" enrichissements js dans une page HTML
par contre pas du tout lorsqu'il s'agit de construire sont interface en javascript.

je pense donc qu'il n'y a pas de comparaison à avoir sur la facilité d'utilisation ou la richesse fonctionnelle.

pour moi c'est comme comparer un avions avec un bus de ville ce sont tout deux des moyen de transport mais avec l'un il va être particulièrement compliqué d'aller à la boulangerie du coin tandis qu'avec l'autre ce sera compliqué d'aller assister aux oscars au départ de paris.

je ne nie pas que Zendx peu donner un coup de main comme par exemple aller mettre les script file dans l'entête de la vue.

mais je reste septique pour un usage intensif.
l'exemple que tu donne pour traiter le problème que je soulevait en est l'illustration

si je n'aime pas js et que ne le connais pas Zendx dans ce cas là ne m'aide pas puisqu'il faut tout même que j'en connaisse la syntaxe pour écrire l'affectation.
dans ce cas là j'aurais bien apprécié quelque chose comme

<?php $this->jQuery()->set('myVar', $this->name);

qui là effectivement me permet de faire du pthp et d'affecter à une variable js une valeur de php
mais comment faire alors pour encasuler sans la notion d'objet de js sans que le développeur n'ai à la connaitre et sans faire une usine à gaz.

A+JYT

Chacun compare comme il le veut.
Perso, je compare JQuery et Dojo a des agglos et de briques.
Les 2 permettes de faire aussi bien une petite qu'une grande maison.
Mais chacun personnes a ses préférences pour l'un ou l'autre, chacun voit les "propriétés" de la matière qui l'intéresse.

Je ne vois vraiment pas (et ne comprends pas) pourquoi dire que JQuery n'est pas adapté à un usage intentif (je ne parle pas de ZendX !). Il n'y a aucune limite. Les limites sont seules celles qu'on s'impose soit-même

Je ne vois vraiment pas (et ne comprends pas) pourquoi dire que JQuery n'est pas adapté à un usage intentif (je ne parle pas de ZendX !). Il n'y a aucune limite. Les limites sont seules celles qu'on s'impose soit-même

Tu n'as pas compris, nous parlons de performances lorsqu'il s'agit d'utiliser ZendX, pas jQuery seul car dans ce cas on peut mettre au point un système qui permet de ne pas recompiler le JS à chaque fois. Mais pas avec ZendX


A+ benjamin.

alien7 a écrit:

On peut aussi les comparer sur les performances :
http://docs.jquery.com/Release:jQuery_1.3#Performance
Là JQuery s'en sort très bien par rapport à Dojo, surtout la 1.3.
++

JQuery comme son nom l'indique est avant tout un moyen de récupérer rapidement dans un DOM des éléments et de leur appliquer des fonctions.

Si on prend des librairies constructives, lorsqu'on construit un objet on l'a sous la main il est inutile de le chercher ni de le modifier on le construit tel qu'on en a besoin.

avec jquery on va au contraire produire du HTML qui sera interprété par le DOM puis cherché l'objet crée pour le transformer.

si tu a disons 20 000 composant dans ton javascript tu vas minimum 20 000 fois chercher un truc et 20 000 fois appliquer des transformations
alors que dans une approche constructive tu fait le tout en une seule fois

ensuite pour rendre les composants dynamiques et faire en sorte qu'ils interagissent entre eux tu vas dans jQuery leur attacher des fonction qui elle même vint chercher l'objet sur lequel agir pour enfin effectuer l'action.

Alors qu'avec une approche constructive lorsque tu construit un composant tu lui fourni le handler mais aussi la référence à l'objet sur lequel il doit agir.

avec une approche comme JQuery c'est très pratique lorsque tu as déjà une page HTML et que tu veux lui ajouter une fonctionnalité au travers de js Car jQuery est très efficace pour retrouver les éléments et les transformer.

alors qu'avec une approche constructive si tu as déjà une page HTML il est moins facile de prendre un élément existant pour le transformer mais plus facile d'ajouter un composants

donc si je part d'une page déjà existante JQuery est plus facile à utiliser (il a été conçu pour) si je part d'une page blanche un approche constructive ce montre plus pertinente.

Quand à la taille c'est l'évidence même. si lorsqu'on a un petit nombre d'objet ce n'est pas pénalisant de les chercher à tout va. Lorsqu'on en a un très grand nombre mieux vaux ne pas passer sont temps à les chercher.
je m'explique avec jQuery je fais du html

<html><div id='a45'></div></html>

le DOM l'interprète et donc js ne va pas manipuler mon html mais le résultat de cette interprétation (chose que beaucoup de développeurs js oublient)

document
    +--Head
    +--Body
           +--div id->a45

pour en faire un composant dynamique jQuery va m'aider aler le chercher

$('#a43').

qui va lui même produire un nouveau DOM dans le quel lors de l'invocation du handler il faudra chercher l'objet cible
Avec un approche constructive

var cible = new MyComponent({...});
var a43 = new OtherComponent({
    ....
    handler : function () {cible.myMethod();}
});

dans ce cas on part d'un DOM vide et on y place des composants js vu qu'on les construit en js il n'est pas besoin de les chercher pour en garder des référence (var cible = ...) lorsqu'on active un handler pas besoin de chercher la cible on l'a déjà il suffit d'invoquer la méthode

sur 1000 objets faire 1000 recherches de quelque nano secondes ce n'est pas grand chose. sur 20 000 ça commence à changer la donne et sur 100 000 ça n'a plus rien à voir.

Je conclu donc de mon expérience que jQuery est particulièrement bien adapté lorsqu'on veut transformer un DOM pour lui ajouter quelques élements dynamique et que des truc comme ExtJs eux sont plutôt destiné à construire des IHM en Javascript.

A+JYT

Je suis assez d'accord sur le fait de ne pas utiliser ZendX_jQeury ou Zend_Dojo pour ne gérer le javascript qu'au niveau des vues mais comment insérer un datepicker dans un form gérer avec Zend_Form par exemple ?

Retour sur une vieille discu
toujours dans l'approche de construire un application du type RIA connecté à un serveur PHP
et non une WebApp (enchainement de pages)

j'ai aujourd'hui fais mes premiers pas avec Cappuccino (sproutcore nécessite plus de ressources pour commencer)
Donc une Application HTML5 entièrement en Objective-J connecté avec AJAX à un serveur PHP
pour la partie php j'ai repris un vieux dev batit sur la même architecture mais avec une partie client en ExtJS. donc les méthodes JSON à invoquer existe déjà.
c'est le côté client que j'ai exploré

mes premières impressions sont mitigées.
trois solution s'offraient à moi.
1) Full Objective-J
2) CIB avec Xcode et interface builder
3) CIB avec Atlas

la dernière solution bien que très séduisante coûte 20$ Atlas est une application écrite avec cappuccino qui permet de dessiner son interface comme interface Builder d'apple. mais multiplateforme (il suffit d'avoir un navigateur)
CIB pour cappuccino interface builder est un format de fichier qui décrit l'interface.
je n'ai donc pas testé. mais peu de différence avec la 2) le point important étant que Atals marche sur toutes plateforme et produit directement le CIB.

la 2) nécessite d'avoir un Mac (ça tombe bien j'en ai à la maison depuis 1986) il faut installer les outils dans Xcode après c'est du dev à la Mac. il faut ensuite untiliser nib2cib pour transformer les fichier IB mac en CIB
gros inconvénient il faut un mac

enfin la solution 1) full objective-j
là un seul langage à connaitre objective-j. je n'ai pas trouvée de difficulté majeure à cela. je n'ai pas perçu de différence avec objective-c (ou alors inconsciemment je les ai gommées) c'est un langage à objet dynamique classique basé sur des classe (javascript un un langage à objet orienté prototype)
difficulté la doc est pauvre. (encore plus qu'avec ExtJS) c'est verbeux mais la logique est claire. bref ça demande de pisser du code.

- (id)init
{
    var theWindow = [[CPPanel alloc]
        initWithContentRect:CGRectMake(0, 25, 225, 125)
        styleMask:CPHUDBackgroundWindowMask | CPClosableWindowMask];

    self = [super initWithWindow:theWindow];

    if (self)
    {
        [theWindow setTitle:@"Inspector"];
        [theWindow setFloatingPanel:YES];

        var contentView = [theWindow contentView],
            centerX = (CGRectGetWidth([contentView bounds]) - 135) / 2;

        scaleSlider = [[CPSlider alloc]
            initWithFrame:CGRectMake(centerX, 13, 135, 16)];

        [scaleSlider setTarget:self];
        [scaleSlider setAction:@selector(scale:)];

        [scaleSlider setMinValue:50];
        [scaleSlider setMaxValue:150];
        [scaleSlider setValue:100];

par exemple pour créer une petite fenêtre "inspector" avec un curseur

bref c'est un peu laborieux mais c'est relativement clair
la syntaxe n'est pas habituelle pour tout le monde les [] permette d'appeler une méthode d'un objet ou une classe

[CPSlider alloc] <>= new CPSlider (); //en php

on peut avec de l'habitude le lire dans le texte

        scaleSlider = [[CPSlider alloc]
            initWithFrame:CGRectMake(centerX, 13, 135, 16)];

Créer un nouveau CPSlider et l'initialier avec le frame ....
lorsqu'on a plusieurs argument on voit dequoi il s'agit

CPPanel     initWithContentRect    styleMask

passé les premier pas ça deviens facile à lire et à écrire.
le plus dur étant le manque de doc

tout cela ne concernait que la partie V de MVC
je rappelle que Cappuccino est un framework qui implémente MVC.

pour la partie M peut de chose à dire c'est du grands classique Ajax encapsulé dans des objets qui gèrent les paragdimes observer et delegation donc lorsqu'une valeur change dans un objet métier et qu'elle est affiché dans la vue la vue est mise à jour automatiquement (la position d'un curseur va changer tout seule). de même pour les mise à jour

reste le contrôler qui lui va devoir faire le lien entre tout ça. il va instancier ou référencer les objets métier et créer la vue. puis il va associer les objets de la vue au objets métier correspondants et orchestrer tout ça.


voilà rien d'extraordinaire. c'est riche bien fait et on sent un for potentiel.
pour une application à l'IHM à la Itune c'est un peu long (je maitrise pas encore) mais ce n'est pas compliqué. et surtout on ne s'occupe plus du tout de HTML CSS et autre truc du genre. on fait une application

je me suis posé la question concernant CIB cib à la maim c'est possible mais pas facile, avec Atlas c'est payant, avec Xcode il faut un mac.
je le suis souvenu d'un truc renaissance (GnuStep et Xcode) j'ai regardé la chose et il ne semble pas compliqué de le porter sous Cappuccino. on obtient alors quelque chose de beaucoup plus concis que le code pur.
mais cela implique d'en passer par XML.
je ne sais pas quelle est la meilleure approche.

je n'ai pas non plus testé sur du dev lourd (30 000 lignes de code pour le RIA)
comment ce comporte le navigateur ?

enfin dernier point c'est déjà HTML5 natif
car même si on ne le voit pas cappuccino reste une application HTML CSS JS dans un navigateur

A+JYT

Dernière modification par sekaijin (07-04-2010 15:05:48)

Je remonte ce très vieux sujet de plus d'un an. Cela pourrait paraître superflu, mais je trouve que le débat évolue. Avec la sortie des nouvelles générations de navigateurs et HTML5, le débat revient sur la table.

De notre côté, pour les formulaires, nous avions à l'époque hésité entre deux solutions :
1 - Zend et JQuery
2 - Zend et Dojo

Nous développons essentiellement des applications Web pour de la gestion d'annexes, gestion de contenus et des solutions métiers bien ciblés. Le choix s'est porté sur Dojo. Nous en sommes particulièrement satisfaits. Nous avions une contrainte forte sur l'accessibilité de nos applications. Elles subissent donc deux phases de tests :
1 - Développement pour un navigateur récent (Dernières versions officielles de Chrome et version aurora de Firefox, désormais Firefox 5 Beta)
2 - Tests sur ces navigateurs avec une feuille de style spécifique permettant une meilleure visibilité et une meilleure écoute et sans javascript

Dojo répond très bien à notre demande et fonctionne parfaitement. Nous sommes au final très content de notre choix. Les pages sont compatibles XHTML1.0 STRICT.

Mais avec HTML5, nous avons décidé de remettre le débat sur la table. Et là franchement, nous avons d'agréables surprises et des questions qui nous ennuient énormément. Les agréables surprises sont la sémantique d'HTML5, ses aides, ses superbes bonus ergonomiques. À l'inverse, il y a des hic. Exemple de point noir : la réglette pour sélectionner un nombre entier (exemple du curseur de volume)

[lang=html] <input type="range" min="0" max="100" value="20" step="5"/>

Au niveau accessibilité, c'est inutilisable pour nous, car les navigateurs pour personnes à déficience visuelle ne le gère pas. Nous restons donc sur le format text, même si la possibilité d'utiliser le format number est plus qu'envisagée. (Mais IE est encore trop à la traîne). Nous avons donc banni le type range. Les autres formulaires de types date sont par contre très bien car on peut saisir la valeur manuellement et on a des messages d'erreur de validation sans user de Javascript. Et cela nous plait beaucoup. Bien sûr côté serveur, nous continuons de faire les tests de validations.

Au final, comme il s'agit de solutions intranet, notre décision actuelle est de passer nos applications en HTML5, de mettre un message pour les usagers d'IE et de choisir un vrai navigateur (ok je trolle un peu là ^^), nous gérons la portabilité sur IE9. Nous faisons un lien vers ce document : http://html5readiness.com/ et nos clients adhèrent et font pression sur leurs équipes informatiques pour obtenir Firefox ou Chrome qui ne sont pas réticentes, bien au contraire !

Au final, comme seul Opéra gère les formulaires de type date, time, nous n'utilisons pas les formulaires spécifiques. Tout reste en input type="text" avec Dojo comme validateur client et les validateurs habituels côté Serveur. Par contre, nous utilisons bien les attributs required, autofocus et surtout placeholder qui s'avère extrêmement pratiques et très ergonomique dans les champs de formulaire.

En espérant que notre retour d'expérience vous ait servi !

Dernière modification par Alexandre_T (27-06-2011 16:37:14)

Petite question à vous 2 : le manque d'accessibilité dans HTML5 est-il dû à un réel manque dans HTML5 ou à sa jeunesse et donc à sa non-prise en compte par les navigateurs alternatifs (pour déficients visuels, ...) ?