Zend Framework 1.0.0 : PHP à la suite de Ruby on Rail

Posté par  . Modéré par Jaimé Ragnagna.
Étiquettes :
0
2
juil.
2007
PHP
Déjà aperçu dans ces colonnes, le Zend Framework marque une date dans son histoire. Après trois versions candidates, ZF est produit en version 1.0.0 finale, le tout sous licence New BSD comme depuis le début.

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. Zend est une société fondée par Andi Gutmans et Zeev Suraski (le nom Zend est un mot-valise de leurs prénoms Zeev et Andi) et connue pour son moteur de langage de script à la base du langage PHP (depuis la version 4) : le moteur Zend. Le moteur Zend a été un accélérateur du succès de PHP.

Cette fois-ci, Zend continue d'améliorer ses outils de développement web, mais en aval cette fois ci en proposant un framework de développement web pour PHP5. Un framework est un espace de travail modulaire, un ensemble de bibliothèques permettant le développement rapide d'une application.

On pense à PEAR, un ensemble de classes suivant des conventions de développement et installable depuis un outil en ligne de commande. ZF est plus cohérent et plus restreint. Par exemple, il n'y a pas deux classes qui font le même travail. Le suivi est donc beaucoup plus exigeant par rapport à PEAR.

L'ensemble des classes de ZF est réparti en deux grosses parties : ZF Core et ZF Incubator. On aura vite compris la distinction. Dans le premier cas ce sont les classes fonctionnelles, stables et maintenues tandis que le second cas contient les classes ayant vocation à rejoindre Zf Core à terme.

ZF Core est lui même réparti en composants répondant à différentes problématiques. Par exemple la problématique de l'authentification et de l'autorisation propose les paquets Zend_Acl, Zend_Authentication et Zend_Session et leurs classes respectives. Ainsi de suite pour l'accès aux bases de données, l'i18n & la l10n, le MVC et quelques autres.

À noter que l'accès aux bases de données utilise l'abstraction PDO ou certaines extensions spécifiques de PHP (tel Mysqli). Le but du ZF n'est pas d'implémenter une nième abstraction du SGBDR, mais de fournir une implémentation de la représentation et de conception de requêtes, transitions modèle relationnel-modèle objet, etc.

Le gros avantage que l'on peut trouver à ZF par rapport à certains frameworks (par exemple symphony), c'est qu'on est loin d'une usine à gaz. La découpe en composants permet d'utiliser ceci sans cela, avec une flexibilité qui rappelle furieusement celle de PEAR. L'arborescence de l'application imposée par MVC est très flexible et très légère. Il est très facile de choisir son moteur de modèle (par défaut c'est PHP, bien sûr) pour opter pour le tout aussi connu que lourd Smarty.

Zend a vraiment fait jouer la communauté. Fort de l'énorme popularité de PHP tant chez les petits bidouilleurs de scripts infâmes et bardés de failles de sécurité que chez les professionnels. Les contributions sont nombreuses. Le site est orienté pour attirer les contributeurs. Cependant, il faut noter que Zend garde les rênes du projet et les contributeurs doivent signer un accord de licence des contributeurs permettant de formaliser les contributions en vue de se protéger d'attaques juridiques telle celle de SCO. Les contributeurs ont et gardent leurs droits sur la contribution. Le ZF est distribué sous licence New BSD, licence approuvée par l'OSI, mais qui pose problème selon la FSF, voir l'article Le problème de la licence BSD sur le site du projet GNU.

Assez rapidement, ZF a été utilisé malgré son état alpha. De fait, certaines évolutions ont cassé la compatibilité ascendante, mais des paramétrages permettent malgré tout de faire tourner une application conçue avec ZF 0.8beta dans un environnement avec ZF 1.0.0 moyennant peu de changement de code (notamment au niveau de l'implémentation du MVC).

ZF serait-il déjà victime de son succès ?

Aller plus loin

  • # mouais

    Posté par  (site web personnel) . Évalué à 10.

    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

      Posté par  . Évalué à 9.

      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

        Posté par  . Évalué à 0.

        PHP 5.X ... peut être un véritable environnement OBJET de développement

        C'est pas un peu trop dès le Lundi matin ?
        • [^] # Re: mouais

          Posté par  (site web personnel, Mastodon) . Évalué à 10.

          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

            Posté par  . Évalué à 7.

            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.

            Envoyé depuis mon lapin.

            • [^] # Re: mouais

              Posté par  . Évalué à 7.

              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

              Posté par  (site web personnel) . Évalué à 6.

              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.


              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

                Posté par  . Évalué à 0.

                "ç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

                  Posté par  (site web personnel) . Évalué à 6.

                  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.

                  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

                    Posté par  . Évalué à 1.

                    Digérer les bons concepts tout de suite... pourquoi pas mais ça risque d'aller au détriment de la popularité.


                    - Comment je fais pour écrire dans le fichier ?
                    - Attends, faut d'abord que je t'explique le typage, l'héritage, le polymorphisme, la poo, blahblah...
                    - Ouais... laisse tomber, je vais faire un *.bat.


                    Pourriware is not a crime. ;-)
                    • [^] # Re: mouais

                      Posté par  . Évalué à 3.


                      f = File.new('fichier','w+')
                      f.puts 'Texte de test'

                      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.

                      Envoyé depuis mon lapin.

                      • [^] # Re: mouais

                        Posté par  (site web personnel) . Évalué à 3.

                        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).

                        Pourriware is not a crime. ;-)

                        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

                          Posté par  . Évalué à 0.


                          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 que fais-tu du plaisir d'apprendre ? C'est pourtant une vraie bonne raison.
                        • [^] # Re: mouais

                          Posté par  . Évalué à 2.

                          Tiens... On est collègues ?

                          /me retourne se pendre avec des méthodes de 4000 lignes à modifier...
                      • [^] # Re: mouais

                        Posté par  . Évalué à 5.

                        ok... alors encore plus rapide:


                        file_put_contents('fichier','texte de test');


                        ;-)
                        • [^] # Re: mouais

                          Posté par  . Évalué à 2.

                          Ouais, mais pour la suite, c'est moins pratique.

                          Envoyé depuis mon lapin.

                          • [^] # Re: mouais

                            Posté par  . Évalué à 2.

                            Je te laisse expliquer ça au nouveau venu, pendant ce temps là je me rencarde sur ruby ;-)
                    • [^] # Re: mouais

                      Posté par  . Évalué à 2.

                      Pourriware is not a crime. ;-)
                      Peut être pas, mais dans certaines situations, cela peut valoir le pal.

                      Au minimum.
                  • [^] # Re: mouais

                    Posté par  . Évalué à 2.

                    Le problème c'est que trop souvent le passage à la deuxième étape (du code propre quoi) est limité / oublié


                    ben j'ai commencé avec du crados (je n'arrive même plus à lire mes vieux scripts) et j'ai progressivement utilisé l'objet et différent pattern. L'existant du site dont je m'occupais était ma plus grosse barrière, pas php en lui même.
              • [^] # Re: mouais

                Posté par  (site web personnel, Mastodon) . Évalué à 0.

                - $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)


                Tel que tu décris ce processus, c'est tout à fait normal. Ça s'appelle le polymorphisme.
                • [^] # Re: mouais

                  Posté par  (site web personnel) . Évalué à 2.

                  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

                  $this est une référence à l'objet appelé (habituellement, l'objet auquel la méthode appartient, mais ce peut être un autre objet si la méthode est appelée de manière statique depuis le contexte d'un autre objet)


                  Après, peut-être que tu vas m'expliquer que c'est tout à fait normal, mais là comme ça, je vois pas...
                  • [^] # Re: mouais

                    Posté par  (site web personnel, Mastodon) . Évalué à 2.

                    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

                      Posté par  . Évalué à 1.

                      $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

                Posté par  . Évalué à -1.

                * 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

                  Posté par  . Évalué à 3.

                  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

                    Posté par  (site web personnel) . Évalué à 2.

                    ce serait pas également possible avec nombre de langages tels que les langages à prototype (lua, javascript, ...) ?
                  • [^] # Re: mouais

                    Posté par  . Évalué à 2.

                    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

                      Posté par  . Évalué à 3.

                      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

                        Posté par  . Évalué à 0.

                        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

                          Posté par  . Évalué à 3.

                          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

                            Posté par  . Évalué à 0.

                            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

                              Posté par  (site web personnel) . Évalué à 4.

                              > 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

                                Posté par  . Évalué à 2.

                                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

                              Posté par  . Évalué à 3.

                              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

                                Posté par  . Évalué à 2.

                                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

              Posté par  . Évalué à 3.

              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.

              Ç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 ;)
              • [^] # Re: mouais

                Posté par  . Évalué à 2.

                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

            Posté par  . Évalué à 5.

            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

              Posté par  (site web personnel) . Évalué à 7.

              > 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

              Posté par  . Évalué à 5.

              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
            • [^] # Commentaire supprimé

              Posté par  . Évalué à 5.

              Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: mouais

            Posté par  . Évalué à 3.

            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...

            Sans allez dans une conception très poussée de la notion d'objet comme Smalltalk, on est encore loin de Java ;)
            • [^] # Re: mouais

              Posté par  (site web personnel) . Évalué à 7.

              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

                Posté par  . Évalué à 1.

                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
                • [^] # Re: mouais

                  Posté par  . Évalué à 4.

                  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

                    Posté par  . Évalué à 3.

                    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
                • [^] # Re: mouais

                  Posté par  (site web personnel) . Évalué à 1.

                  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

      Posté par  (site web personnel, Mastodon) . Évalué à 7.

      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

        Posté par  . Évalué à 2.

        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.
        • [^] # Re: mouais

          Posté par  . Évalué à 3.

          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

            Posté par  . Évalué à 3.


            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 ...


            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.


            Si tu peux faire ce que tu veux ce n'est plus un framework.


            donc je pense que tu ne peux pas faire ce que tu veux, cependant tu peux utiliser q'une partie du framework.


            ZF est plus une sorte de méta-framework, et serait une excellente base pour créer un 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 :)
            • [^] # Re: mouais

              Posté par  (site web personnel) . Évalué à 3.

              > 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

                Posté par  . Évalué à 2.

                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.
            • [^] # Re: mouais

              Posté par  . Évalué à 1.

              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

        Posté par  . Évalué à 4.

        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é ;-)
    • [^] # Re: mouais

      Posté par  . Évalué à -1.

      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.
  • # Framework PHP

    Posté par  (site web personnel) . Évalué à 8.

    Bien qu'en concurrence avec les autres projets de framework, ZF encourage la création de framework PHP. (symphony , CodeIgniter , CakePHP , QCodo ).


    Autre framework que l'on peut citer (puisque son auteur est trop humble pour le citer lui même) :

    Jelix : http://jelix.org/

    Jelix est un framework pour PHP5 :

    * entièrement objet, performant
    * prend en charge de nombreux formats de sortie (XHTML, XUL, RDF..)
    * facilite le développement de services web
    * conçu sur la base de modèles connus (MVC, DAO..)
    • [^] # Re: Framework PHP

      Posté par  . Évalué à -3.


      Autre framework que l'on peut citer (puisque son auteur est trop humble pour le citer lui même)


      Ou alors il en a trop honte !
      • [^] # Re: Framework PHP

        Posté par  (site web personnel) . Évalué à 7.


        Ou alors il en a trop honte !


        Pour l'avoir évalué et utilisé à divers stades de maturité, je pencherai plutôt pour l'humilité. Y'a pas à dire, c'est du beau code, pratique et efficace, malgré les légitimes bugs et trous de jeunesse (vivement la 1.0). Ce qui ne m'a pas empêché de faire des vrais projets avec (rien de public cependant). Le développement est actif et les patches que j'ai envoyés ont été rapidement intégrés. Pour moi, c'est le meilleur !
  • # >> Python et Plone ?!?!

    Posté par  . Évalué à 3.

    Heu... si on veut comparer à Ruby et RoR ce serait plutôt Python+Zope, nan ?

    Même si ce satané Zope est absolument inclassable et tient tout autant de l'IDE, du Framework que de la Forge en ligne. Zope, ovni ou précurseur ? Le débat est ouvert.
    • [^] # Re: >> Python et Plone ?!?!

      Posté par  . Évalué à 4.

      Je sais pas du tout ce que c'est que ce nouveau bouzin en PHP, mais juste histoire de citer Django, Turbogears, Nevow et compagnie :)
    • [^] # Re: >> Python et Plone ?!?!

      Posté par  . Évalué à 2.

      Je ne connais pas bien Zope, on me l'a souvent décris plus comme un serveur d'application qu'un framework. Pour ceux qui connaissent contrairement à moi, c'est une affirmation juste ?
      • [^] # Re: >> Python et Plone ?!?!

        Posté par  (site web personnel) . Évalué à 2.

        Zope est un serveur d'application et un framework de développement. Par contre ce n'est pas un IDE (à moins que vi et ed soient des IDE).
        Plone est un site web prêt à l'emploi qu'il est possible de personnaliser en ligne et un framework de développement pour ceux qui souhaitent avoir d'autres fonctionnalités que celles proposées par défaut.
        • [^] # Re: >> Python et Plone ?!?!

          Posté par  . Évalué à 1.

          C'est aussi un IDE, vu qu'il fournit des outils basiques d'édition des scripts depuis l'interface d'admin. D'ailleurs, tout le tutorial est basé là-dessus et je ne me rappelle plus de la possibilité de passer outre cet IDE.
          • [^] # Re: >> Python et Plone ?!?!

            Posté par  (site web personnel) . Évalué à 3.

            C'est bien ce que je disais: un IDE va beaucoup plus loin qu'un simple éditeur, sinon vi et ed (et dd) sont des IDE. Zope n'est pas un IDE, il est juste orienté TTW (Throught The Web) pour l'administration quotidienne.
    • [^] # Re: >> Python et Plone ?!?!

      Posté par  . Évalué à 3.

      Précurseur ? Si je te dis que la 1ere version est sortie en 96 (libéré fin 98), tu en penses quoi ? :).

      Oui clairement, avec Web Objects de Next (sorti aussi en 96), qui permet de développer une application Web un peu comme une application classique, au détriment d'une prise en main plus complexe que PHP 2 et 3 ou ASP (on doit penser objet, MVC, utilisation d'un ORM par défaut, la notion d'héritage à l'éxécution....).

      Et puis, dans le monde Python, on faisait pas de pub. Il faut remonter à 2005/2006 pour voir un véritable début de communication (refonte du site web, création d'une ml marketing...) avec comme exemple RoR. Et c'est bien dommage, Python s'est fait bouffé par PHP alors qu'il avait bien plus d'atouts. Et Zope Corp. est le plus mauvais élève en la matière, avec un produit révolutionnaire, des core devs impliqués dans la vie de l'interpréteur, Zope est resté opaque (peu de doc, pas de livre...) et méconnu par beaucoup de monde, même dans le monde Python.

      Et ca continue avec Zope 3, qui est une refonte from scratch. Y'a pas mal d'idées fort intéressantes, qui ne se trouvent pas dans les RoR, Tg, Django, qui sont "des versions modernes" de Zope 2 (dans l'esprit).

      Bref, OVNI ou précurseur, les 2 mon capitaine. Et ca risque de pas trop changer, sauf si Plone arrive à démontrer la puissance du produit (ce qui est plutot bien parti avec Plone 3) sur les 2 prochaines années.
      • [^] # Re: >> Python et Plone ?!?!

        Posté par  . Évalué à 3.

        Python s'est fait bouffé par PHP alors qu'il avait bien plus d'atouts


        Je dirais plutôt que php s'est imposé dans le monde du développement web pour ses atouts propres. Au début quand il est arrivé le développement web se résumait à des scripts perl en cgi, or le modèle lamp a fait beaucoup pour la démocratisation des outils de développement web. A cette époque python n'était pas du tout sur les rangs comme un language utilisable facilement pour faire du web. Aujourd'hui python est une alternative très crédible, ce qui n'a pas toujours été le cas.

        Quant à Zope ca n'est pas non plus pour rien qu'il est "resté opaque": courbe d'apprentissage longue, très mal documenté, et aussi gros consommateur de ressources.

        les RoR, Tg, Django, qui sont "des versions modernes" de Zope 2 (dans l'esprit).


        A mon sens Zope n'est en rien comparable à des Rails ou Django: on a là un serveur d'applications et non un framework mvc, la base objet amenant un fonctionnement radicalement différent. Les bonnes idées se trouvant dans Zope sont contrebalancées par la lourdeur de l'ensemble: beaucoup de couches imbriquées, beaucoup de mécanismes à connaitre. Et apparement ca ne s'arrange pas dans Zope 3: la philosophie est vraiment différente d'un "convention over configuration", dans le sens ou Zope 3 est conçu comme un ensembles de composants qu'il faut lier ensemble en se paluchant pleins de fichiers de conf xml. Ceci dit plein de bonnes idées dans Zope 3 d'après ce que j'ai entendu.

        Pour conclure sur une touche positive, je suis bien d'accord pour dire qu'aujourd'hui python rox pour le développement web.
        • [^] # Re: >> Python et Plone ?!?!

          Posté par  (site web personnel) . Évalué à 3.

          > Je dirais plutôt que php s'est imposé dans le monde du développement web pour ses atouts propres.

          Je confirme, et l'atout de PHP est encore inégalé : pouvoir faire tourner facilement des serveurs mutualisés de manière simple. PHP avec feu son safe mode et son open base dir est vraiment un avantage.

          (Oui, je sais que ces fonctions ne sont pas la panacées et que c'est souvent troué, mais il n'empêche que si PHP s'est démocratisé c'est grace à plein de serveurs gratuits qui se reposaient là dessus).

          Allez faire du gros mutualisé en Ruby ou en Python .. c'est faisable mais c'est une toute autre affaire.
          • [^] # Re: >> Python et Plone ?!?!

            Posté par  (site web personnel) . Évalué à 2.

            php a gagné des parts de marché avec easyphp qui installait en 3mn php + mysql sous Windows. php a gagné via Windows et non via UNIX. C'est là que python et perl ont perdus.

            Sinon, refait un tour du coté de perl car perl, c'est un peu plus que des petits scripts CGI. Cela fait 10 ans que perl fait de l'objet avec des namespace... Je te conseille de faire un tour sur le CPAN pour voir ce que signifie un développement communautaire.

            Sinon, pour l'autre débat du thread : zope. Personnellement, je n'aime pas du tout et autour de moi, les gens ont aussi horreur de ce truc. C'est peut être très puissant mais je fais un blocage total sur la ZMI et l'édition en mode web.
            • [^] # Re: >> Python et Plone ?!?!

              Posté par  . Évalué à 3.

              php a gagné (...) / (...) python et perl ont perdus.


              Personne n'a gagné ni perdu, les technologies comme les besoins évoluent c'est tout. Le web s'invente au fur et à mesure. Php va faire son temps, comme les autres.
            • [^] # Re: >> Python et Plone ?!?!

              Posté par  (site web personnel) . Évalué à 6.

              > php a gagné des parts de marché avec easyphp qui installait en 3mn
              > php + mysql sous Windows. php a gagné via Windows et non via
              > UNIX. C'est là que python et perl ont perdus.

              PHP a commencé à être populaire avant le haut débit et avant easyphp. Easyphp a beaucoup apporté mais je persiste, ce qui a permis tout ça c'est bien les possibilités d'hébergement mutualisé en masse. Sans ça ça aurait fait une belle jambe à l'époque d'avoir un easyphp local.


              > Sinon, refait un tour du coté de perl car perl, c'est un peu plus que des petits scripts CGI.

              J'ai dit le contraire ?
              Mais perl c'est aussi une syntaxe très discutable pour la plupart des gens et un hébergement pas si simple. Bref, on retire les deux raisons qui font que php est populaire.
              Ca n'empêche pas qu'on peut faire des gros trucs bien avec (et on les fait), comme dans n'importe quel langage, mais on n'est pas du tout sur le même créneau que PHP.
              • [^] # Re: >> Python et Plone ?!?!

                Posté par  (site web personnel) . Évalué à 2.

                La syntaxe du php est la même que celle du Perl, tout du moins à l'origine. Donc la syntaxe n'est pas un argument recevable pour ma part. Par contre, pour l'herbergement, je suis d'accord, avec php, l'herbergement Perl n'a pas suivis.
                • [^] # Re: >> Python et Plone ?!?!

                  Posté par  (site web personnel) . Évalué à 2.

                  > La syntaxe du php est la même que celle du Perl, tout du moins à l'origine.

                  Déjà le langage actuel n'a plus grand chose à voir avec ce qu'il était au départ. Donc juger de la syntaxe de php 3/4/5 sur ce que ça a pu être au niveau du début non public de PHP, ça ne me parait pas pertinent.

                  Après non, justement, PHP a été écrit en Perl au départ. S'il y a eu un interpréteur de créé sur Perl c'est forcément *justement* pour ne pas taper du Perl.
                  • [^] # Re: >> Python et Plone ?!?!

                    Posté par  (site web personnel) . Évalué à 2.

                    Nous sommes d'accord je pense pour dire que php s'éloigne petit à petit du perl et cela est normal. Le php5 notament qui introduit une couche objet.

                    Pour ce qui est de l'origine de php, pour l'avoir connu et pour avoir réalisé des sites en perl avant que le php n'existe, je lisais du code php sans aucun apprentissage alors que lire du python (ou du ruby) sans aucun apprentissage que le perl n'est pas aussi évident que cela.

                    Je connais plein de gens qui ont développé des sites en php sous Windows et qui ne voulait pas entendre parler du Perl, plus par effet de mode que par réelle conviction puisqu'il n'avait jamais fait une ligne de perl. Lorsque tu leurs montrait qu'il y avait une abstraction DBI pour attaquer n'importe quelle base de données plutôt que les fonctions merdiques du php de l'époque, cela ne changeait rien à leur fonctionnement. Idem si tu allait faire un tour sur le CPAN... D'ailleurs, la plupart n'était pas programmeur pour un sous et n'avaient pas la moindre notion de sécurité. Par exemple, toutes les requêtes sur la base de données étaient faites en 'admin' avec tous les droits, même pour de simple SELECT.

                    Bref, je reste persuadé qu'il a manqué à Perl un easyphp à une époque et c'est vraiment dommage car on a un langage de script en plus qui n'apporte pas grand chose aujourd'hui, mais bon, c'est un avis personnel. C'est comme pour les moteurs de tous ces langages, les spécialistes feraient mieux de tous bosser sur Parrot que de multiplier les différents moteurs plus ou moins performant.

                    Mais bon, There Is More Than One Way To Do It !
          • [^] # Re: >> Python et Plone ?!?!

            Posté par  . Évalué à 2.


            Oui, je sais que ces fonctions ne sont pas la panacées et que c'est souvent troué,


            à priori ça va sauter avec php6
            • [^] # Re: >> Python et Plone ?!?!

              Posté par  . Évalué à 3.

              a priori ça va sauter avec php6

              Remplacé par quoi ?
              • [^] # Re: >> Python et Plone ?!?!

                Posté par  . Évalué à 0.

                Remplacé par quoi ?

                Par une nécessité de rigueur.
              • [^] # Re: >> Python et Plone ?!?!

                Posté par  (site web personnel, Mastodon) . Évalué à 3.

                par rien. Le safe_mode est grosse daube, le cauchemar des développeurs dés lors que l'on veuille manipuler des fichiers dynamiquement. (y a qu'à lire les notes de releases des projets phares en PHP, qui souvent déconseillent l'utilisation du safe mode parce que ça provoque des problèmes de lectures/ecritures de fichiers, à cause de droits &co).

                Bon debarras le safe_mode !

                open_basedir reste par contre, et c'est déjà bien pour sécuriser un compte web.
                • [^] # Re: >> Python et Plone ?!?!

                  Posté par  . Évalué à 3.

                  y a qu'à lire les notes de releases des projets phares en PHP, qui souvent déconseillent l'utilisation du safe mode parce que ça provoque des problèmes de lectures/ecritures de fichiers, à cause de droits &co

                  Disons qu'il faut régler préalablement les droits d'accès à certains répertoires.
                  Sinon le safe_mode_gid était un bon compromis (en conjonction avec le sticky bit - chmod g+s sur les répertoires).

                  open_basedir reste par contre

                  Ok. Mais il faut penser à désactiver toutes les fonctions dangereuses (ce que le safe mode faisait automatiquement si je ne m'abuse).
            • [^] # Re: >> Python et Plone ?!?!

              Posté par  (site web personnel) . Évalué à 3.

              > à priori ça va sauter avec php6

              Seulement le safe mode, pas l'open basedir
    • [^] # Re: >> Python et Plone ?!?!

      Posté par  . Évalué à 5.

      Il faut le comparer à Django ou Turbogears qui sont des frameworks qui supportent le pattern Convention over Configuration
      http://softwareengineering.vazexqi.com/files/pattern.html
  • # ORM ?

    Posté par  . Évalué à 1.

    J'ai découvert il y a peu (à ma grande satisfaction!) ezPDO. Le Zend Framework embarque-t-il ce genre de fonctionnalité? Parce que pour le comparer à Rails ça me semble approprié non?
    • [^] # Re: ORM ?

      Posté par  . Évalué à 2.

      non, ils se dirigent plus vers de l'active records. Et pour avoir eu des situations complexes à gérer avec ezPDO, c'est pas toujours cool le fait de perdre la main sur la base et sur les clé primaires.
      • [^] # Re: ORM ?

        Posté par  . Évalué à 1.

        Quel genre de situation? je m'oriente vers ça donc ça m'intéresse d'avoir un avis plus détaillé...
        • [^] # Re: ORM ?

          Posté par  . Évalué à 2.

          mon avis date de mi - 2006 , les choses peuvent avoir changées depuis.

          ezPDO prend la main sur la BD (il créait même les tables), donc c'est délicat :
          - d'utiliser autre chose que ezPDO pour acceder à ta base.
          - d'utiliser ezPDO sur une base de donnée existante

          ezPDO utilise une unique table pour faire persister les relations entre objets, donc tu peux difficilement dépasser les 20 millions de relations sous mysql 3.2x (d'après moi).

          je voulais gérer un id unique par objet ou pour toute la base je ne sais plus, et cela posait pb , je n'avais pas de moyen simple de le faire. A vérifier.

          les points positifs :
          - à l'époque, la communauté était assez réactive
          - c'est cool si tu ne veux voir que des objets (la base se génère automatiquement)

          perso j'avais besoin d'attaquer la BD directement pour des stats avancées, et je voulais permettre le développement de module sans ezPDO (ct dans le cadre d'un CMS), et c'etait délicat. J'ai donc mis de coté cette solution.
          • [^] # Re: ORM ?

            Posté par  . Évalué à 1.

            Effectivement c'est un peu "tout ou rien". Il faudra que j'essaie sur un petit projet pour voir un peu moi-même les limites.


            je voulais gérer un id unique par objet


            ça à priori tu peux (cf http://ezpdo.net/blog/?p=5)
  • # Prado

    Posté par  . Évalué à 1.

    Il y a aussi le framework Prado ( http://www.pradosoft.com ) pour PHP5.1 sous licence BSD. Les auteurs de ce framework se sont largement inspirés de la philosophie ASP.NET.

    D'ailleurs, la version 3.1 vient de sortir en stable hier.

    Perso, je ne développe plus d'applications Web PHP sans ce framework depuis que je l'ai essayé.
  • # *khof* *khof*

    Posté par  (site web personnel) . Évalué à 4.

    "Pour cela, Zend veut reprendre les recettes qui ont fait le succès de PHP : des solutions simples et élégantes qui fonctionnent partout."

    Comment dire, "qui fonctionnent partout", les gens oublient le merdier des incompatibilités entre version de php, ainsi que les nombreux hacks requis pour adapter les softs à la configuration du serveur ?

    Quand aux "solutions simples et élégantes", c'est vrai que le fait de rajouter i à chaque fontion de matching est "élégant" et pas du tout piégeux. Et que la cohérence des fonctions ( avec ou sans _ ), la duplication des fonctions, etc, tout ça le rends "simple" et "élégant", comme le rappelle ce lien http://tnx.nl/php.

    Php a des avantages, la facilité ( car visiblement, tout le monde arrive à en faire ), le fait qu'il soit pensé pour offrir un systéme de template web à des users sans avoir à leur donner les droits admins, la capacité de limiter les users au niveau des opérations, etc, mais faut pas non plus essayer de nous faire prendre des vesies pour des lanternes.
    • [^] # Re: *khof* *khof*

      Posté par  (site web personnel) . Évalué à 1.

      Moi chui po d'accord.
      Comment dire, "qui fonctionnent partout", les gens oublient le merdier des incompatibilités entre version de php, ainsi que les nombreux hacks requis pour adapter les softs à la configuration du serveur ?

      Quels "hacks" requis pour adapter les softs a la configuration du serveur ?
      A part le fameux register_globals quasiment mort maintenant et déprécié depuis longtemps.. Après, si les serveurs ont une configuration de php vraiment différente d'un à l'autre, faute aux serveurs. Mais personelement, je n'ai jamais eu besoin a recourrir à de telles pratiques bizaroides pour faire fonctioner mes programmes de serveur à serveur.

      cohérence des fonctions ( avec ou sans _ ), la duplication des fonctions, etc
      Encore une foi,c'est personel, mais je trouve que rajouter "_" uniquement pour les fonctions dites "magiques" c'est réellement coérent. Tu parlai peut-être d'autre chose ?
      Puis concernant la "duplication des fonctions". moi j'emploi plutôt le terme de "proffusion" de fonctions, certaines en effets relativements similaires, et parfois aussi des alias, mais qui pour moi sont un atout, et permettent une plus grande clarté pour peu que l'on conaisse un peu / suffisament le language et les-dites fonctions, même si il est vrai, un débutant ne conaissant pas spécifiquement php peu s'embrouiller dans les noms.
      • [^] # Re: *khof* *khof*

        Posté par  . Évalué à 2.


        Moi chui po d'accord.


        moi non plus, pour le principe ;-p

        non, plus sérieusement, je ne connais pas bien python et pas dutout ruby, mais en java, le probleme des incompatibilités entre version de java ou entres serveurs , ou entre systeme ... existe aussi. et en php (je suppose que c'est pareil en JAVA) il suffit de peu de chose pour éviter ces galères (register_globals en est en effet une grosse partie ...).
      • [^] # Re: *khof* *khof*

        Posté par  (site web personnel) . Évalué à 7.

        Quels "hacks" requis pour adapter les softs a la configuration du serveur ?
        A part le fameux register_globals quasiment mort maintenant et déprécié depuis longtemps..


        Les magic quotes, cette "géniale" fonctionnalité qui :

        - Si activée, brise le principe des "données pures" : tu te retrouve avec des chaînes echapées en entrée, ce qui fait que certaines fonctions vont retourner des données bizaroïdes (par exemple, strlen() ne te renverra pas vraiment le nombre de caractères contenus dans la variable).
        - Si activée et que tu veux restaurer des données pures, tu dois avant toute chose prendre toutes les chaînes passer en entrée et les déséchapper à la main avec stripslashes() > HACK qui pue (et complètement débile quand on y pense : on est obligé de refaire en sens inverse ce que PHP a fait automatiquement, quelle logique implacable !)
        - Si un code n'a été prévu pour s'adapter à la configuration des magic quotes du serveur, alors il n'y a aucune chance pour qu'il survive à une migration sur un autre serveur de configuration différente (apparation de bugs tels que des chaînes échapées envoyées au client ou pire de failles de type SQL Injection)

        Il y en a d'autres des options de config qui modifient le comportement de PHP et peuvent faire qu'un script qui fonctionne très bien sur un serveur crashera lamentablement sur un autre, il suffit de consulter la liste des options dans le manuel de PHP pour s'en apercevoir.
        • [^] # Re: *khof* *khof*

          Posté par  . Évalué à 2.

          Magic_quotes ça saute aussi dans php6. En attendant:


          class Tools
          {
          static public function remove_magic_quotes(&$array)
          {
          foreach($array as $key => $val)
          {
          if(is_array($val))
          {
          self::remove_magic_quotes($array[$key]);
          }
          else if(is_string($val))
          {
          $array[$key] = stripslashes($val);
          }
          }
          }
          }


          if(get_magic_quotes_gpc() == 1)
          {
          if(!empty($_POST))
          {
          Tools::remove_magic_quotes($_POST);
          }
          if(!empty($_GET))
          {
          Tools::remove_magic_quotes($_GET);
          }
          }


          et il n'y a plus de problème.
          • [^] # Re: *khof* *khof*

            Posté par  (site web personnel) . Évalué à 5.

            En attendant:
            [vieux hack qui pue]
            et il n'y a plus de problème.


            Tu as lu mon message ? Je dénonçais justement la logique implacable des magic quotes qui fait que si elles sont actives, tu dois refaire à l'envers ce que PHP a fait automatiquement, quelle avancée !
            • [^] # Re: *khof* *khof*

              Posté par  . Évalué à 2.

              Bientôt on aura plus à avoir ce genre de discussion... puisque ça n'existera plus.
          • [^] # Re: *khof* *khof*

            Posté par  (site web personnel) . Évalué à 4.

            Et $_REQUEST alors ?

            Mais oui le "il n'y a qu'à rajouter 30 lignes de script et analyser côté utilisateur toutes les données en entrées pour faire l'inverse de PHP, le tout à insérer au démarrage de chaque script PHP avant le code applicatif", c'est je pense justement ce que le monsieur plus haut appelle un "hack".

            Surtout que le hack en question il est très pénible, chacun fait le sien et en associant des composants entre eux j'ai vu plus d'une fois des projets qui lançaient deux fois l'opération.

            Dire qu'il n'y a plus de problème quand tu as à ajouter ce genre de chose, c'est aller un peu vite.
            • [^] # Re: *khof* *khof*

              Posté par  . Évalué à 1.

              Un hack... ouais, tout de suite les gros mots... :-)

              $_REQUEST je m'en fous, je l'utilise jamais, je ne l'utiliserai sans doute jamais, je ne travaille avec personne qui l'utilise ou qui l'utilisera et je ne l'ai jamais rencontré dans aucune des librairies que j'ai pu utiliser.
              Si tu vas par là tu peux aussi rajouter $_COOKIE.


              Dire qu'il n'y a plus de problème quand tu as à ajouter ce genre de chose, c'est aller un peu vite.


              ok --> *Je* n'ai plus de problême. Et non c'est pas pénible, c'est fait une fois pour toutes. Et non je n'ai pas besoin d'inclure ça dans chaque script php... juste dans UN script, l'index.

              Ce que je veux dire c'est que oui les magic_quotes c'est chiant, mais non ça suffit pas pour jeter le bébé avec l'eau du bain, d'autant que le tir sera corrigé.
          • [^] # Re: *khof* *khof*

            Posté par  . Évalué à 1.

            Remplacer une fonction par une méthode statique d'une classe nommée Tools... Hmm, Java a fait des ravages chez certains.
            • [^] # Re: *khof* *khof*

              Posté par  . Évalué à 3.

              Ha, j'ai cru un moment que j'étais le seul à penser ça, merci Antoine. Quel est l'intérêt de définit une classe dans cet exemple ?
              • [^] # Re: *khof* *khof*

                Posté par  . Évalué à 1.

                Dans cet exemple aucun.
                Par contre le fait de mettre ça dans une classe permet d'appeler cette méthode sans avoir à inclure à la mimine préalablement le fichier la contenant puisque l'autoload s'en occupe.
                Je ne crois pas qu'on puisse faire de même avec une "simple" fonction mais si c'est le cas ça m'intéresse aussi.
              • [^] # Re: *khof* *khof*

                Posté par  . Évalué à 9.

                De pouvoir placer "Framework Orienté Objet" dans son business loto
      • [^] # Re: *khof* *khof*

        Posté par  (site web personnel) . Évalué à 5.

        > Quels "hacks" requis pour adapter les softs a la configuration du serveur ?

        Rien que le magic_quotes_gpc par exemple (encore un truc qui n'aurait jamais du exister)

        > Tu parlai peut-être d'autre chose ?

        Il parlait probablement de (par exemple) isset() plutot que is_set() alors qu'on a is_string() et non isstring().
        La cohérence des fonctions est effectivement un *gros* problème de PHP. Parfois avec les mêmes paramètres ou des paramètres similaires, des fonctions proches les mettent dans un ordre différent. Parfois c'est retourné en valeur de retour et parfois via un paramètre par référence. Résultat on code toujours avec une doc sur le côté pour les prototype, ou un IDE qui fait la complétion.
        • [^] # Re: *khof* *khof*

          Posté par  (site web personnel) . Évalué à 0.

          Bon, ok PHP est un language qui a un ENNORMME defaut: il faut rajouter 2 "hack" de 5 lignes pour le rendre portable de serveurs a serveurs.. mince alors !

          Pour ce qui est des incohérences de noms de fonctions, il est indéniable qu'il en existe, et peut-être plus qu'ailleurs, je ne serai pas de mauvaise foi sur ce point la :)
          Ceci-dit, une foi en tête les 2 ou 3 noms de fonctions problematiques, plus de probleme. en tout cas *je* ne code plus avec la documentation tout le temps sous le nez et les problemes isset/is_set -like n'en sont pas pour moi.

          Enfin bon, bref. je ne pense pas qu'il s'agisse de vrais probleme. Vrais problemes pour qui ne connait pas trop ce language oui mais c'est tout.
          Les vrais problemes sont plutot les limitations côté objet AMHA.
          • [^] # Re: *khof* *khof*

            Posté par  . Évalué à 1.

            Ouf... je commençais à me demander ce que je faisais sur ce forum :-P
        • [^] # Re: *khof* *khof*

          Posté par  (site web personnel) . Évalué à -1.

          A la différence près que :
          * is_string() est une fonction, on peut faire : is_string(<une fonction qui va bien>)
          * isset n'est pas une fonction, mais une structure du langage et on ne peut l'appeler qu'avec des variables (pas de résultats de fonction), isset(<une fonction qui va bien>) renverra une erreur

          Finalement la différence de syntaxe a peut etre une raison ?

          http://fr.php.net/isset
          http://fr.php.net/is_string
          • [^] # Re: *khof* *khof*

            Posté par  . Évalué à 1.

            ça y est, je viens de comprendre le principe de ce forum... les vannes à la con reçoivent des plus et les commentaires argumentés prennent des moins, comme ça au bout d'un moment on voit plus les commentaires et on retrouve plus facilement les vannes pour bien se marrer derrière son écran quand on a rien à faire au boulot.

            C'est quand même bien fait linuxfr...
  • # Symfony

    Posté par  . Évalué à 4.

    e la création de framework PHP. (symphony ,


    symFony :o)

    Zend, à ce que j'en ai vu, ressemble plus à une boite à outil pour développeur. Symfony est un véritable framework. Il est libre et architecturé autour de méthodes de développement professionelles éprouvées. Mélange de RoR, Django (entre autres) avec la facilité d'hébergement et la rapidité du PHP, il est par exemple utilisé par Yahoo sur certains de ses sites grand publique.

    Pour finir, le livre (sous licence libre), écrit par les auteurs du framework, est disponible sur leur site.
  • # codeigniter

    Posté par  (site web personnel) . Évalué à 3.

    Puisque tout le monde sort son framework, voici codeigniter :
    http://codeigniter.com/

    Compatible php 4 et 5, il est très leger et peut utiliser les bibliothèques du pseudoframework Zend :)
    • [^] # Copix

      Posté par  (site web personnel) . Évalué à 1.

      Puisque nous sommes sur le sujet, je rappelle l'existence de Copix : http://www.copix.org/ un framework complet et qui bénéficie de nombreuses années de développement. La sortie de la version 3.0 est imminente.

      Des plugins permettent l'utilisation des classes ZF et les classes ezComponents.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.