Développeur : Zend Framework 1.0.0 : PHP à la suite de Ruby on Rail
Posté par Étienne Bersac (Jabber id, page perso, ). Modéré le 02 juillet 2007.
Le but de Zend Framework est de fournir un ensemble de composants de très haute qualité pour le développement web en PHP 5, avec une documentation de l'API et un manuel maintenu continuellement. Pour cela, Zend veut reprendre les recettes qui ont fait le succès de PHP : des solutions simples et élégantes qui fonctionnent partout.
Bien qu'en concurrence avec les autres projets de framework, ZF encourage la création de framework PHP. (symphony , CodeIgniter , CakePHP , QCodo ).
Gageons que ZF jouira d'un certain succès. Le libre ayant déjà par ailleurs une très nette domination dans le développement web avec Ruby et RoR, Python et Plone, voire Java et Apache. L'avenir nous dira si Zend Framework est ou n'est pas un clou de plus sur le cercueil du web propriétaire.
![[en]](../images/en.png)
Zend framework (1180 hits)![[fr]](../images/fr.png)
Communauté francophone de développeurs Zend (910 hits)-
Téléchargements (212 hits)
-
Feuille de route (193 hits)
-
PHP (140 hits)
-
QEDwiki, un exemple d'utilisation de ZF (Flash) (419 hits)
> Lire la dépêche (119 commentaires, moyenne: 2,8).
Vous avez demandé le commentaire #847743.
Run by 
Cette page a été générée par Templeet en 0.1867s (dont 0.0186 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
mouais
mouais
Mettre "à la suite de Ruby On Rails" dans le titre c'est chercher les coups. Je ne me lancerai pas dans une argumentation sur Ruby On Rails mais ZF c'est un ensemble de briques élémentaires à peine collées ensemble. On est très loin d'un framework intégré et complet. C'est d'ailleurs à la limité entre une bibliothèques de composants et un framework. Comparer ça à Ruby On Rails (ou même à symfony ou Plone) c'est aller plus que vite en besogne.
Ce qu'ils font est bien, même si ça va assez lentement par endroits et que le résultat n'est pas très "sexy" mais c'est encore loin des autres solutions intégrées.
Note tout de même parce que je suis étonné de trouver ça ici : on parle bien de "new BSD", autrement appelée "BSD modifiée". Le texte de la FSF à propos du problème BSD c'est justement pour l'"ancienne" BSD avec la clause de publicité. Il n'y a aucun problème avec cette licence (même si certains préféreront peut être un copyleft).
[^]Re: mouais
Je suis entièrement d'accord, arrêtons d'appeler un Framework tout est n'importe quoi.
Le seul est intérêt de ZF est de rappelé au monde que PHP 5.X n'est plus un simple langage de script mais peut être un véritable environnement OBJET de développement. Sur ce point là ZF est une très bonne chose.
[^]Re: mouais
C'est pas un peu trop dès le Lundi matin ?
dyslectics have more fnu
[^]Re: mouais
Peut-être devrais tu te pencher un peu plus sur le modèle objet de PHP 5 ? On est loin de celui de PHP3 ou PHP4 hein...
On peut faire des choses très propres en objet avec PHP5.
Certes, il manque peut être quelques trucs par rapport à d'autres langages objets super avancés (namespace par exemple, mais ça viendra dans PHP6), mais le minimum est là et bien là, et suffit déjà largement à faire des trucs convenables. On a pas toujours besoin de l'artillerie lourde des autres langages pour faire un bon soft.
[^]Re: mouais
Le problème que j'ai trouvé avec php, c'est que le modèle objet est (ou donne l'impression) d'être une couche rajoutée sur une base fonctionnelle.
L'esprit est pas orienté objet dans php. Il suffit de constater l'énorme liste de fonctions, avec un nom différent pour chaque action.
[^]Re: mouais
Pour être franc jusqu'à PHP 4.X je partage ton avis. Je refusais même de faire de l'objet.
Par contre depuis PHP 5.X je ne fais que de l'objet au quotidien sur des applications grands compte à forte audience (centaines de milliers d'utilisateurs), çà tient la charge, le code se structure facilement et est maintenable, grâce à l'utilisation de framework notamment.
[^]Re: mouais
Selon moi c'est clairement une couche rajoutée à l'arrache par dessus ; il n'y a qu'à voir tous les problèmes d'implémentations (mais d'après la doc, c'est pas des bugs, c'est des *features*), par exemple :
- Impossible de dériver une méthode statique (parceque pas de late static binding), ce qui supprime un paquet de possibilités de conception objet
- $this qui change quand ça lui plait (dans certains cas, quand on appelle une méthode d'une classe A à partir d'une méthode d'une classe B, $this dans la classe A pointe sur... B)
- $this qui n'est rien d'autre qu'une variable vaguement protégée : si on essaye de l'assigner directement ($this = 'toto') on obtient une erreur, par contre il est possible de la modifier en passant par une référence, ou avec certains fonctions comme extract...
Bref, c'est pas encore au point.
[^]Re: mouais
"ça ne marchera ja-mais!" ;-)
Blague à part, le coté objet rajoutée sur une base fonctionnelle,c'est ça qui est chouette... besoin de bricoler un truc en 10 lignes et en 2 minutes? Tu peux. Besoin de plus de méthode? Tu peux aussi :-)
C'est aussi un langage qui permet d'apprendre en douceur... des scripts crados mais simples à comprendre au début, puis une meilleure organisation et le monde de l'objet si on souhaite aller plus loin.
Je ne suis pas en train de dire que tout est parfait mais quand même... ça va dans le bon sens. PHP5 a amorcé un virage vers des pratiques plus saines, ça s'accentuera encore avec PHP6.
[^]Re: mouais
Le problème c'est que trop souvent le passage à la deuxième étape (du code propre quoi) est limité / oublié
Alors qu'avec un bon langage objet bien fait et simple (tout le monde a compris que je parlais de ruby ;) ) on est tout de suite dans la deuxième étape, tout en faisant des choses simples.
[^]Re: mouais
Digérer les bons concepts tout de suite... pourquoi pas mais ça risque d'aller au détriment de la popularité.
Pourriware is not a crime. ;-)
[^]Re: mouais
C'est orienté objet, rapide, et clair.
Au passage, le fichier est automatiquement fermé à la fin du thread. Ruby permet aussi de coder spécialement.
[^]Re: mouais
Exactement, c'est ce qui fait, je trouve, la force du langage Ruby.
Pour moi, Ruby c'est du perl en plus simple et plus beau ;-)
Sérieusement, je conseil à tout le monde de regarder ruby. Je ne dis absolument pas que tout le monde doit coder en ruby, mais le modèle objet de ruby est assez sexy et vraiment intéressant.
Et on a je trouve justement un langage dans lequel on peut coder vite et bien (ruby étant assez succint).
ben en fait presque...
pour moi, un bon code doit être tant que possible un beau code
l'avantage de commencer en écrivant du code propre, est qu'on en prend assez vite l'habitude et donc on continue a faire des choses propres. Ca n'empèche pas de faire du code un peu roots mais ça doit être vraiment limité.
Le problème de commencer par du code sale mais qui marche est qu'on a aucune raison d'écrire proprement puisque ça marche... et changer ensuite de façon de coder n'est pas forcément simple.
Le résultat que j'en ai vu, c'est des fichiers h/cpp assez halucinant :
dans le même .h : 300 lignes de defines suivit des définitions de 11 structures et 7 classes (dont l'une d'environ 700 lignes sans commentaires, tous les attributs étant en plus public évidemment).
Le .cpp correspondant fait un peu plus de 46000 lignes, avec des fonctions de plusieurs milliers de lignes, des imbrications type :
if / while / if / if / switch / switch / if / switch
et des fonctions prenant 21 paramètres.
Alors oui ça marche (c'est en prod) ... mais putain que c'est crade !
Pour moi un code doit être beau, se lire relativement facilement (ça dépend évidemment des algos derrières mais si on en fait abstraction ça doit être facile à lire) et compiler sans erreurs ni warnings
/me a fini son petit moment evangeliste de beau code ;-)
[^]Re: mouais
Et que fais-tu du plaisir d'apprendre ? C'est pourtant une vraie bonne raison.
[^]Re: mouais
Tiens... On est collègues ?
/me retourne se pendre avec des méthodes de 4000 lignes à modifier...
[^]Re: mouais
ok... alors encore plus rapide:
;-)
[^]Re: mouais
Ouais, mais pour la suite, c'est moins pratique.
[^]Re: mouais
Je te laisse expliquer ça au nouveau venu, pendant ce temps là je me rencarde sur ruby ;-)
[^]Re: mouais
Peut être pas, mais dans certaines situations, cela peut valoir le pal.Au minimum.
[^]Re: mouais
ebaobab.net - Partagez avec vos amis tout en conservant votre vie privée !
[^]Re: mouais
Tel que tu décris ce processus, c'est tout à fait normal. Ça s'appelle le polymorphisme.
[^]Re: mouais
En quoi c'est du polymorphisme ? Je me suis peut-être mal exprimé : il n'y a *aucune* relation entre la classe A et la classe B. Une méthode de B execute une méthode de A, c'est tout.
C'est simplement une "feature" liée (selon moi) à l'implémentation légèrement foireuse de $this, de la gestion du contexte et des méthodes statiques (encore elles).
Documenté par ici : http://fr3.php.net/manual/fr/language.oop5.basic.php
Après, peut-être que tu vas m'expliquer que c'est tout à fait normal, mais là comme ça, je vois pas...
[^]Re: mouais
je pensais effectivement que B dérivait de A dans ton explication. Désolé.
C'est vrai que ce que tu décris pourrait paraître un bug par rapport à d'autres langages objets. Pour moi effectivement, $this ne devrait pas avoir d'existence dans une méthode statique, puisque ce n'est pas une méthode d'un objet instancié.
Mais bon, si ils déclarent dans PHP que ça se passe autrement, pourquoi serait-ce un mal ? Surtout si ladite méthode est explicitement déclarée avec "static" ? (et donc le développeur, sachant le comportement de $this, sait à quoi il s'attend puisqu'il s'agit effectivement d'une méthode statique)
[^]Re: mouais
$this n'a pas a appeler du static au travers de $this, c'est self::nomMethodeStatique() qui devrait être imposé, c'est un bug.
C'est une chose qui relève plus d'un problème de mentalité chez php que d'un problème objet, php encourage un laxisme navrant dans le language, j'apprécie les capacités techniques de php et son modèle objet par contre de base ils partent du principe que même si un développeur écris n'importe quoi il faut que çà marche.
[+] [^]Re: mouais
* une méthode statique est une méthode appartenant non pas à un objet mais à une classe, donc la dériver c'est un contre sens en POO, ce n'est pas parce que certains langage font n'importe quoi qu'il faut imiter.
* Pour le deuxième point je demande à voir sur un exemple concret. Car l'affirmation me parait grosse
* pour le fait de changer $this par extract forcément si tu voulais savoir qu'un langage çà se casse, je te fais des exemples équivalent en JAVA, C++ quand tu veux.
Enfin le modèle objet n'est pas une surcouche vu que c'est le moteur objet de Zend sur lequel se repose PHP, le modèle objet est écris à un niveau plus que l'implémentation même du PHP.
Il n'empêche que point de vue ergonomie d'utilisation de modèle objet, je préfère d'autres langages que le php (ruby par exemple) mais ce n'est qu'une question de goût
[^]Re: mouais
une méthode statique est une méthode appartenant non pas à un objet mais à une classe, donc la dériver c'est un contre sens en POO
Tu oublies que dans certains langages objets pas totalement bridés (*) , une classe est aussi un objet. Donc dériver une méthode statique (plus exactement une méthode de classe) est tout à fait normal.
Enfin c'est rigolo de voir des gens qui parlent de "POO" en restreignant toujours leur horizon à la sémantique de langages comme Java ou PHP.
((*) exemple : Python)
[^]Re: mouais
ce serait pas également possible avec nombre de langages tels que les langages à prototype (lua, javascript, ...) ?
[^]Re: mouais
Justement parce que je ne limite pas ma vision à l'implémentation objet d'un langage, je ne valide pas la pertinence d'une pratique par le fait qu'un langage permet de le faire ou pas, mais uniquement sur la pertinence en terme d'architecture et de conception.
[troll]
Et un langage qui ne gère pas la notion d'entité sans état correctement (classe) est un langage qui bride bien beaucoup je trouve.
[/troll]
[^]Re: mouais
je ne valide pas la pertinence d'une pratique par le fait qu'un langage permet de le faire ou pas, mais uniquement sur la pertinence en terme d'architecture et de conception.
Sauf que pour le coup tu n'as rien démontré.
[^]Re: mouais
ben non car je pensais que tu maitrisais certains basique.
l'intérêt d'un objet est de rattacher des traitements à des états propres à chaque localité (du fait de l'existence des attributs), une classe statique est une entité qui ne peut avoir qu'un seul état à un moment donné.
La conséquence est que l'on a pas besoin de se rattacher à une instance pour manipuler l'état en cours. L'absence d'instance fait que l'état est disponible de façon globale de n'importe où.
Cette accessibilité globale fait que la surcharge ou l'héritage sur une entité à un seul état possible (élément statique) n'a pas de sens, car n'ammène aucune flexibilité supplémentaire :
Tu as besoin de récupérer une fonctionnalité statique ? Elle est disponible depuis n'importe quel endroit du code, donc héritage inutile.
Tu as besoin de personnaliser une fonctionnalité statique ? tu appelles ta fonctionnalités statique récupère le résultat et le retravaille, donc surcharge inutile.
l'intérêt de l'héritage et de la surcharge est de pouvoir factoriser et personnaliser des fonctionnalités sous forme hiérarchique sur toutes les états existant d'une entité, car tu gardes dans tes attributs d'instance, l'état spécifique à chaque instance tout en récupérant tes fonctionnalités déjà écrites.
Bref c'est du basique de POO.
[^]Re: mouais
ben non car je pensais que tu maitrisais certains basique.
Tsss...
une classe statique est une entité qui ne peut avoir qu'un seul état à un moment donné.
Une classe n'est "statique" que 1) si le langage en a décidé ainsi, ou 2) si l'idéologue (toi en l'occurence) a décidé qu'il devait en être ainsi.
Cette accessibilité globale
Une classe n'est pas nécessairement globale (sauf dans ton monde à toi, bis repetita).
L'absence d'instance fait que l'état est disponible de façon globale de n'importe où.
Pardon, mais là où je me place une classe est une instance d'une métaclasse. Donc la supposée "absence d'instance"...
Bref, tout ça pour dire que tu as ta vision très particulière de la programmation "orientée objet" et tu as du mal à accepter que certaines implémentations ne s'y conforment pas. Un cours magistral ne vaut que s'il n'est pas contredit par la réalité.
[^]Re: mouais
statique ou pas est un concept, comme la programmation orienté objet est un concept, maintenant si tu n'aimes pas le concept de programmation objet, pourquoi pas.
Maintenant que des implémentations font plus le concept de base, tant mieux, il faut évoluer, mais tout ajout ne devient pas quelque chose d'utile et géniale parce que c'est 'nouveau'. C'est génial quand cela apporte une valeur ajouté dans les problématiques que l'on rencontre dans la conception d'application efficace, maintenable et pérenne.
Je n'utilise pas un langage pour faire un étalage de syntaxe histoire que la programmation soi plus fun, un langage est un outil qui doit à travailler mieux, et plus vite.
Maintenant si je me trompe et que cet ajout à une réelle valeur ajoutée, expliques moi, je ne demande qu'à comprendre, en attendant, j'ai argumenté mes propos.
Prend le cas du Ruby, il a certains aspects qui peuvent paraitre exotique dans son implémentation de l'objet, mais ces spécificités se sont révélées souvent utiles pour mieux architecturer l'application. En plus d'autres facteurs totalement irrationnels de l'ordre du goût personnel, font que c'est mon langage préféré niveau objet.
Par rapport au python qui est en soit un super langage, tu présentes certaines spécificités comme un plus, explique en quoi c'est un plus ? Si c'est juste pour dire sur le papier python fait çà que tel autre langage ne fais pas ... intérêt zéro, si par contre cela apporte un mécanisme qui simplifie l'implémentation de certains design pattern, alors super !! Ce truc est génial.
Donc les implémentations des langages c'est le dernier de mes soucis, tu présentes quelques choses de spécifiques, explique en quoi cette spécificité est un plus et non un simple argument de l'ordre "qui a la plus grande".
[^]Re: mouais
> Maintenant que des implémentations font plus le concept de base, tant mieux
Java n'est pas "le concept de base".
Que le statique d'une classe soit en fait une instance d'autre chose (la méta classe), ça découle directement que la classe est un objet à part entière. C'est au contraire en plein dans le concept objet que de pouvoir faire tout ça.
Ce n'est pas parce que Java a asséché l'objet en ne gardant qu'une partie que c'est la philosophie objet qui veut ça.
Si spécificité il y a par rapport au modèle objet, c'est plutot Java qui l'a (vu que Java a fait le choix de ne pas tout mettre en objet mais de présenter aussi des concepts informatiques "en dur" : types primitifs, classes, interfaces, etc.).
D'ailleurs Ruby n'est en rien "spécial" de ce côté là. Les langages qui permettent de représenter les classes sous forme objet sont légion.
[^]Re: mouais
Je n'ai jamais affirmé que Java est le concept de base, ne te méprend pas sur ce que j'ai voulu dire, je me suis mal exprimé.
Je suis d'accord et partage ton avis sur tous les points.
[^]Re: mouais
Coupons court, ton blabla m'insupporte.
mais tout ajout ne devient pas quelque chose d'utile et géniale
Je n'ai pas dit que tout était génialement utile, je répondais à l'origine à ta grosse connerie selon laquelle, je cite, "une méthode statique est une méthode appartenant non pas à un objet mais à une classe, donc la dériver c'est un contre sens en POO". Que tu t'arc-boutes sur un discours abstrait et péremptoire ne me donne pas envie de continuer cette discussion.
Quant à savoir pourquoi dériver une méthode de classe peut présenter une utilité, tu le découvriras bien un jour en quittant les discours creux et en programmant pour de vrai.
[^]Re: mouais
Pour ce qui est de faire de la programmation objet à longueur de journée, ben c'est ce qui me fait manger chaque jours.
"une méthode statique est une méthode appartenant non pas à un objet mais à une classe, donc la dériver c'est un contre sens en POO", c'est mon opinion, tu ne l'as partage pas, tant mieux et il faut de la diversité de discours je ne suis pas contre, par contre tu as contre argumenté par rapport à l'implémentation d'un langage ce qui est à côté du propos.
Et ma grosse connerie elle a été argumenté contrairement à ta position d'offusqué !
Alors tu peux essayer de jouer au grand par ton ton condescendant, tu n'en rendras que plus creuse ta position.
[^]Re: mouais
Ça veut dire que php est un langage fonctionnel comme Haskell ? Ou ça veut juste dire que PHP est conçu pour être adapté à sa fonction ?
PS:
Tant pis si je me fais encore moinsser hein ;)
dyslectics have more fnu
[^]Re: mouais
Ni l'un, ni l'autre, je pense qu'il voulait dire 'rajoutée sur une base avec des librairie ayant des tas de fonctions', c'est a dire des ensembles de fonctions 'a plat' sans hierarchie.
Je ne pense pas que tu te fasse moinsser pour une demande d'explication sur une phrase pas très clair..
[^]Re: mouais
C'est plus du procédural que du fonctionnel PHP.
[^]Re: mouais
Ou de l'impératif, j'ai posté un peu vite.
[^]Re: mouais
Il manque quand même la surcharge de méthodes et de constructeurs, ce qui n'est pas rien!
Et il faudrait aussi penser à "Objetiser" certains lots de méthodes: fichiers, images, BDD (bon, pour ça y a PDO)...
Devoir se trimballer un $fp, ça va 5 minutes...
[^]Re: mouais
> Il manque quand même la surcharge de méthodes et de
> constructeurs, ce qui n'est pas rien!
La surcharge n'est pas un problème d'architecture objet, c'est un problème d'architecture des langages statiques.
C'est vrai que ça peut être sympa dans certains cas mais dans la grande majorité, quand tu as un langage à typage faible dynamique, tu n'en simplement pas besoin.
> Et il faudrait aussi penser à "Objetiser" certains lots de méthodes
Ca avance mais c'est vrai que là il y a encore du boulot pour proposer des objets qui cachent tout ça.
[^]Re: mouais
La surcharge n'est pas une fin en soi, c'est un moyen parmi d'autres de faire du polymorphisme, et du polymorphisme tu en fais sans problème en PHP.
Ensuite que tu pointes une ressource par une variable $fp, un objet ou autre cela change rien, par contre si tu structures ton code correctement en objet, tu n'as pas cette problématique de te le trimballer en permanence
[^]Re: mouais
Salut,
En python, on peut nommer les paramètres et ommettre ceux qui ont une valeur par défaut. Je trouve cette solution bien plus élégante que la surcharge de fonction, surtout dans le contexte de langage à typage faible comme PHP (ou python).
Cordialement,
Étienne.
E Ultreïa !
[^]Re: mouais
Python est un langage fortement typé mais avec un typage dynamique.
http://fr.wikipedia.org/wiki/Python_%28langage%29
Sinon la primeur des paramètres nommés revient plutôt à tcl.
[^]Re: mouais
Sans allez dans une conception très poussée de la notion d'objet comme Smalltalk, on est encore loin de Java ;)
dyslectics have more fnu
[^]Re: mouais
Allez, personne n'est encore rentré dedans alors j'y saute à deux pieds...
De toute manière, php, c'est du perl simplifié qui a 10 ans de retard sur perl. Honnètement, je n'ai jamais vu l'intérêt de ce langage. Tu peux faire aussi simple en perl et aussi bien plus puissant. Autant le python a une syntaxe qui plait à certain et ruby a une vrai valeur ajoutée, autant php n'a eu q'une seule valeur ajoutée : easyphp qui installait php + mysql sur Windows simplement.
[^]Re: mouais
php, c'est du perl simplifié qui a 10 ans de retard sur perl. Honnètement, je n'ai jamais vu l'intérêt de ce langage.
ah ben si tu ne le vois toujours pas, on ne peut vraiment rien pour toi
Windows has no users. It has hostages.
[^]Re: mouais
Il a raison, le langage en lui-même ne vaut strictement rien : sémantique pauvre et foireuse, bibliothèque standard totalement bordélique, syntaxe paradoxalement peu puissante et verbeuse pour un langage "facile à programmer" (par exemple, pas de notation littérale pour les tableaux ou dictionnaires).
Ce qui fait la force de PHP, c'est son intégration native en environnement Web. Mais cette même intégration avec un langage comme Ruby ou Python serait tout de même beaucoup plus agréable.
[^]Re: mouais
note que j'aimais bien Java (le langage) comme un C++ volontairement simplifié, mais que ses librairies standards me semblaient parfois incohérentes dans leurs nommages de classes ou fonctions^Wméthodes...
...soupçons confirmés en lisant plus un article sur l'histoire de Java : plusieurs équipes s'en sont occupées, chacune prenant un gros bout à sa charge, avec au final une API pas tout à fait homogène
Windows has no users. It has hostages.
[^]Re: mouais
J'attends des arguments plus convaincant de ta part au niveau du langage, pour le moment, je ne vois rien. Sinon, ne t'inquiète pas pour moi, je vivrais bien sans développer de projet sous php, je me suis déjà pas mal amusé par le passé à faire des sites web avec AxKit, ça c'est du framework !
[^]Re: mouais
exactement, le zend framework se rapproche plus d'une bibliothèque comme pear que d'un véritable framework qui propose normalement un cadre complet de développement, avec des normes de nommage, une structure précise de l'application, tant au niveau des objets que des fichiers.
Cela ne veut pas dire pour autant que le Zend Framework n'est pas intéressant. Mais pour moi il n'a de framework que le nom.
[^]Re: mouais
pas tout a fait, il y a une "convention" de structure de l'arborescence :
http://framework.zend.com/manual/fr/zend.controller.modular.(...)
celle ci est customisable, mais permet de l'implicite au niveau de la récupération des vues, et des controlleurs.
je dirais plutôt qu'il y a une manière recommandé d'utiliser le framework, et donc une organisation sous entendu. Dans ce cas on peut réellement l'appeler framework. Mais on peut aussi très facilement en utiliser une partie, ou modifier son comportement, et pour séduire des développeurs php, c'est une obligation.
On peut donc l'utiliser en framework ou en librairie, partiellement ou entièrement.
ebaobab.net - Partagez avec vos amis tout en conservant votre vie privée !
[^]Re: mouais
Je ne suis pas d'accord avec toi, tu prend un langage quelconque, même sans librairies, tu peux structurer ou pas, choisir une architecture ou pas.
Le framework impose une architecture, car l'un des objectifs d'un framework est d'enlever au maximum le travail d'analyse au développeur. C'est pour cela par contre que tu as des frameworks spécialisés, framework web, appicatif, réseaux etc ...
Si tu peux faire ce que tu veux ce n'est plus un framework.
Zend propose pleins de fonctionnalités et de classes, pour aider sur pleins de choses, mais n'a pas de norme imposé, mais une logique globale.
Le principe de framework universelle est un peu un contre sens par rapport au but d'un framework, qui est spécialisé pour un sous ensemble d'application.
ZF est plus une sorte de méta-framework, et serait une excellente base pour créer un framework.
[^]Re: mouais
Mais le ZF impose une architecture,
- si tu utilise Zend_Controller_* , cela implique que tu utilise le pattern MVC
- si tu utilise Zend_Log, le framework t'impose l'utilisation de writers, de filters et formatters
- si tu utilise Zend_Session, le namespace est imposé
maintenant, tu peux utiliser la partie MVC et directement les sessions PHP. Grossomodo tu pends les contraintes/aides du framework que tu souhaite, pas toutes en bloc, et ca j'aime. J'ai pu ainsi utiliser le MVC mais aussi continuer à utiliser $_SESSION sans que le MVC en patisse.
donc je pense que tu ne peux pas faire ce que tu veux, cependant tu peux utiliser q'une partie du framework.
je pense surtout qu'il manque des couches "haute niveau" qui utilise les briques de base du framework, mais il faut un debut à tout :)
ebaobab.net - Partagez avec vos amis tout en conservant votre vie privée !
[^]Re: mouais
> si tu utilise Zend_Session, le namespace est imposé
En même temps les sessions c'est un des seuls trucs qui justement ne méritait pas qu'on y fasse une abstraction via une classe utilisateur. Le set_save_handler contient déjà tout ou presque. Là ça complexifie pour pas grand chose.
[^]Re: mouais
je suis assez d'accord, et c'est donc l'avantage du ZF, tu choisis ce que tu trouve bien.
peut - être que certaines personnes ont trouvé un avantage a cette gestion des sessions, particulièrement sur un projet multi dev.
ebaobab.net - Partagez avec vos amis tout en conservant votre vie privée !
[^]Re: mouais
Cela impose tel architecture "si tu utilises ...".
MVC est une extension parmis d'autres, donc adieu la normalisation imposé d'un framework.
Ce que je critique n'est pas la qualité de la technologie qui est superbe mais le fait que l'on appel "framework" quelque chose qui n'est pas un framework.
Le problème est que dire que l'on utilises un framework cela fait bien, donc on appel tout et n'importe quoi un "framework". Surtout que dans beaucoup de cas un framework n'est pas justifié, et c'est à ce marché là que répond ZF.
[^]Re: mouais
En fait, pour utiliser ce framework en ce moment, je trouve qu'il faut pondre beaucoup de code pour faire peu d'actions.
Par exemple, une authentification avec mise en session plus gestion des droits, je le fais en quelques lignes, alors que le ZF en demande bien plus.
Mais je pense que ce framework est fait pour être étendu, je suis d'ailleurs actuellement en train de réaliser ce projet.
Sinon, je préférais la forme de Zend_Filter du début, et je trouve que Zend_Db a bien gagné en rapidité ;-)
http://ethtezahl.over-blog.com/
http://www.grattadom.com
[+] [^]Re: mouais
Et mettre "à la suite de Ruby on Rail" (sans s) c'est faire une faute de frappe.
Sinon, moi je dis chapeau au développeurs PHP qui arrivent à faire de chouettes applis (mediawiki, etc.) avec un tel langage.
[^]Re: mouais
tsss...
[^]Re: mouais
c'est bas, très bas... :)
(a propos de wiki dokuwiki est une perle, lui aussi en php)
ebaobab.net - Partagez avec vos amis tout en conservant votre vie privée !