Articles précédents : Développeur
- [17] Mesa 7.0 : OpenGL 2.0 et 2.1
- [50] Anjuta 2.2.0 - Hurricane - est sorti
- [23] AJAX Chat Engine a besoin de vous
- [24] Première version stable de la forge CodingTeam
- [40] Akrogen, greffon Eclipse de génération de code, avec wizard pages décrits en XML/XUL
- [4] Trophées du libre 2007 : vous pouvez postuler dès maintenant !
- [15] Développer des composants graphiques en PHP
- [13] Un aperçu de Netbeans 6.0
- [13] Blocs notes BasKet à la recherche de développeurs
- [88] OCaml 3.10.0 est sorti
Liens connexes
- Zend framework (1201 clics)
- Communauté francophone de développeurs Zend (939 clics)
- Téléchargements (223 clics)
- Feuille de route (203 clics)
- PHP (152 clics)
- QEDwiki, un exemple d'utilisation de ZF (Flash) (431 clics)
Dépêche modérée par
Dépêche éditée par
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 (1201 clics)![[fr]](../../../images/fr.png)
Communauté francophone de développeurs Zend (939 clics)-
Téléchargements (223 clics)
-
Feuille de route (203 clics)
-
PHP (152 clics)
-
QEDwiki, un exemple d'utilisation de ZF (Flash) (431 clics)
> Lire la suite (119 commentaires, moyenne: 2,8). [dépêche : 4537 caractères]
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 ?
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
Posté par or zax () le 02/07/2007 à 08:40. (lien). É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 totoro () le 02/07/2007 à 08:45. (lien). É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 ?--
dyslectics have more fnu-
[^]Re: mouais
Posté par Laurent J (page perso, ) le 02/07/2007 à 08:55. (lien). É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 yellowiscool (Jabber id, page perso, ) le 02/07/2007 à 09:07. (lien). É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.-
[^]Re: mouais
Posté par or zax () le 02/07/2007 à 09:23. (lien). É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 cgo2 (page perso, ) le 02/07/2007 à 17:34. (lien). É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 choon () le 02/07/2007 à 18:06. (lien). É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 CrEv (page perso, ) le 02/07/2007 à 18:12. (lien). É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 choon () le 02/07/2007 à 18:30. (lien). É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 yellowiscool (Jabber id, page perso, ) le 02/07/2007 à 19:30. (lien). É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.-
[^]Re: mouais
Posté par CrEv (page perso, ) le 02/07/2007 à 20:23. (lien). É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
-
[^]Re: mouais
Posté par Christophe Chailloleau-Leclerc (Jabber id, page perso, ) le 03/07/2007 à 15:56. (lien). Évalué à 2.Tiens... On est collègues ?
/me retourne se pendre avec des méthodes de 4000 lignes à modifier...
-
-
[^]Re: mouais
Posté par choon () le 02/07/2007 à 20:45. (lien). Évalué à 5.ok... alors encore plus rapide:
file_put_contents('fichier','texte de test');
;-)-
[^]Re: mouais
Posté par yellowiscool (Jabber id, page perso, ) le 02/07/2007 à 20:49. (lien). Évalué à 2.Ouais, mais pour la suite, c'est moins pratique.
-
[^]Re: mouais
-
-
-
-
[^]Re: mouais
-
-
[^]Re: mouais
Posté par louis perrier () le 02/07/2007 à 22:01. (lien). É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 Laurent J (page perso, ) le 03/07/2007 à 09:45. (lien). É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 cgo2 (page perso, ) le 03/07/2007 à 15:27. (lien). É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 Laurent J (page perso, ) le 03/07/2007 à 17:40. (lien). É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 or zax () le 03/07/2007 à 17:55. (lien). É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 or zax () le 03/07/2007 à 17:33. (lien). É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 Antoine () le 04/07/2007 à 14:41. (lien). É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 CrEv (page perso, ) le 04/07/2007 à 15:18. (lien). Évalué à 2.ce serait pas également possible avec nombre de langages tels que les langages à prototype (lua, javascript, ...) ?
-
[^]Re: mouais
Posté par or zax () le 04/07/2007 à 19:59. (lien). É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 Antoine () le 05/07/2007 à 13:56. (lien). É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 or zax () le 06/07/2007 à 21:39. (lien). É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 Antoine () le 06/07/2007 à 22:25. (lien). É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 or zax () le 06/07/2007 à 23:08. (lien). É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 Éric (Jabber id, page perso, ) le 07/07/2007 à 10:23. (lien). É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
-
-
[^]Re: mouais
Posté par Antoine () le 07/07/2007 à 11:11. (lien). É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 or zax () le 07/07/2007 à 20:15. (lien). É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 totoro () le 03/07/2007 à 08:53. (lien). É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 ;)--
dyslectics have more fnu-
[^]Re: mouais
Posté par reno () le 03/07/2007 à 10:59. (lien). É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 Thomas Douillard () le 03/07/2007 à 11:56. (lien). Évalué à 2.C'est plus du procédural que du fonctionnel PHP.
-
[^]Re: mouais
Posté par Thomas Douillard () le 03/07/2007 à 11:57. (lien). Évalué à 2.Ou de l'impératif, j'ai posté un peu vite.
-
-
-
-
-
[^]Re: mouais
Posté par windu.2b (Jabber id, page perso, ) le 02/07/2007 à 09:29. (lien). É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 Éric (Jabber id, page perso, ) le 02/07/2007 à 09:33. (lien). É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 or zax () le 02/07/2007 à 09:35. (lien). É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
-
[^]Re: mouais
Posté par Étienne Bersac (Jabber id, page perso, ) le 02/07/2007 à 11:58. (lien). Évalué à 5.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
Posté par Bozo_le_clown () le 02/07/2007 à 14:23. (lien). Évalué à 5.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
Posté par totoro () le 02/07/2007 à 10:01. (lien). É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 ;)--
dyslectics have more fnu-
[^]Re: mouais
Posté par Sytoka Modon (page perso, ) le 02/07/2007 à 19:48. (lien). É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 Gniarf () le 04/07/2007 à 12:45. (lien). É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--
"Je n'aime pas votre regard, baissez les yeux!" - Patrick Devedjian, 2008-
[^]Re: mouais
Posté par Antoine () le 04/07/2007 à 14:44. (lien). É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 Gniarf () le 04/07/2007 à 18:35. (lien). É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--
"Je n'aime pas votre regard, baissez les yeux!" - Patrick Devedjian, 2008
-
-
[^]Re: mouais
Posté par Sytoka Modon (page perso, ) le 06/07/2007 à 19:02. (lien). É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 Laurent J (page perso, ) le 02/07/2007 à 08:58. (lien). É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 louis perrier () le 02/07/2007 à 10:04. (lien). É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 or zax () le 02/07/2007 à 12:25. (lien). É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 louis perrier () le 02/07/2007 à 21:41. (lien). É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 Éric (Jabber id, page perso, ) le 03/07/2007 à 08:10. (lien). É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 louis perrier () le 03/07/2007 à 10:16. (lien). É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 or zax () le 03/07/2007 à 11:30. (lien). É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 ethtezahl () le 02/07/2007 à 11:33. (lien). É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 alpage (Jabber id, page perso, ) le 02/07/2007 à 13:42. (lien). É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.-
[^]Re: mouais
Posté par Damien ARISTODEMO (page perso, ) le 02/07/2007 à 19:23. (lien). Évalué à 1.[...] avec un tel langage.
tsss...
-
[^]Re: mouais
Posté par louis perrier () le 02/07/2007 à 21:44. (lien). Évalué à 2.c'est bas, très bas... :)
(a propos de wiki dokuwiki est une perle, lui aussi en php)
-
Framework PHP
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 Axel () le 02/07/2007 à 11:57. (lien). É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 Obi MO (page perso, ) le 02/07/2007 à 12:31. (lien). É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 ?!?!
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.
J'vais te mettre cette bande d'électrons au garde-à-vous et ça va filer droit, c'est moi qui t'le dit !
-
[^]Re: >> Python et Plone ?!?!
Posté par Émilien Tlapale (page perso, ) le 02/07/2007 à 12:12. (lien). É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 or zax () le 02/07/2007 à 12:33. (lien). É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 Encolpe DEGOUTE (page perso, ) le 02/07/2007 à 13:21. (lien). É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 lezardbreton (Jabber id, page perso, ) le 02/07/2007 à 15:50. (lien). É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 Encolpe DEGOUTE (page perso, ) le 03/07/2007 à 07:06. (lien). É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 Sébastien Douche () le 02/07/2007 à 13:19. (lien). É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 _p4_ () le 02/07/2007 à 19:16. (lien). É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 Éric (Jabber id, page perso, ) le 02/07/2007 à 19:32. (lien). É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 Sytoka Modon (page perso, ) le 02/07/2007 à 19:55. (lien). É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 ?!?!
-
[^]Re: >> Python et Plone ?!?!
Posté par Éric (Jabber id, page perso, ) le 03/07/2007 à 08:15. (lien). É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 Sytoka Modon (page perso, ) le 06/07/2007 à 18:56. (lien). É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 Éric (Jabber id, page perso, ) le 07/07/2007 à 10:26. (lien). É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 Sytoka Modon (page perso, ) le 07/07/2007 à 13:02. (lien). É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 choon () le 02/07/2007 à 21:22. (lien). É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 Antoine () le 02/07/2007 à 21:40. (lien). Évalué à 3.a priori ça va sauter avec php6
Remplacé par quoi ?-
[^]Re: >> Python et Plone ?!?!
Posté par Taku (page perso, ) le 03/07/2007 à 01:02. (lien). Évalué à 0.Remplacé par quoi ?
Par une nécessité de rigueur.
-
[^]Re: >> Python et Plone ?!?!
Posté par Laurent J (page perso, ) le 03/07/2007 à 09:55. (lien). É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 Antoine () le 03/07/2007 à 12:15. (lien). É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 Éric (Jabber id, page perso, ) le 03/07/2007 à 08:17. (lien). Évalué à 3.> à priori ça va sauter avec php6
Seulement le safe mode, pas l'open basedir
-
-
-
-
-
[^]Re: >> Python et Plone ?!?!
Posté par Bozo_le_clown () le 02/07/2007 à 14:27. (lien). É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 ?
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 louis perrier () le 02/07/2007 à 21:49. (lien). É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 choon () le 03/07/2007 à 05:12. (lien). É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 louis perrier () le 03/07/2007 à 07:59. (lien). É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 choon () le 03/07/2007 à 13:34. (lien). É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
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é.
-
[^]Re: Prado
Posté par baud123 (Jabber id, page perso, ) le 03/07/2007 à 16:30. (lien). Évalué à 2.ça tombe bien, ta dépêche est publiée :) https://linuxfr.org/2007/07/03/22693.html
*khof* *khof*
"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 Damien ARISTODEMO (page perso, ) le 02/07/2007 à 19:46. (lien). É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 louis perrier () le 02/07/2007 à 21:57. (lien). É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 e-t172 (page perso, ) le 03/07/2007 à 00:10. (lien). É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 choon () le 03/07/2007 à 05:21. (lien). É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 e-t172 (page perso, ) le 03/07/2007 à 08:21. (lien). É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*
-
-
[^]Re: *khof* *khof*
Posté par Éric (Jabber id, page perso, ) le 03/07/2007 à 08:31. (lien). É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 choon () le 03/07/2007 à 13:13. (lien). É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 Antoine () le 03/07/2007 à 12:18. (lien). É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 lezardbreton (Jabber id, page perso, ) le 03/07/2007 à 12:58. (lien). É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 choon () le 03/07/2007 à 13:28. (lien). É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*
-
-
[^]Re: *khof* *khof*
Posté par Bozo_le_clown () le 03/07/2007 à 13:29. (lien). Évalué à 9.De pouvoir placer "Framework Orienté Objet" dans son business loto
-
-
-
-
-
[^]Re: *khof* *khof*
Posté par Éric (Jabber id, page perso, ) le 03/07/2007 à 08:23. (lien). É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 Damien ARISTODEMO (page perso, ) le 03/07/2007 à 22:00. (lien). É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*
-
-
[+] [^]Re: *khof* *khof*
Posté par Jérôme FIX (page perso, ) le 05/07/2007 à 07:05. (lien). É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 choon () le 05/07/2007 à 17:26. (lien). É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...-
[^]Re: *khof* *khof*
-
-
-
-
Symfony
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
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 Brice Favre (page perso, ) le 03/07/2007 à 08:40. (lien). É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.
Cette page a été générée par Templeet en 0.3888s (dont 0.0545 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.