[OUTILS] Oops, un framework pour PrestaShop

[mexique1]

Salut la communauté,

 

Je suis heureux de partager avec vous un petit framework que j'ai fini par créer au cours de mes développements de modules.

Ca s'appelle Oops (Object Oriented PrestaShop) et c'est un outil de développement de modules.

 

Les fonctionnalités à l'heure actuelle sont :

 

- Construit sur Zend et Propel, permet d'utiliser les 2 frameworks au sein de PrestaShop

- Framework de développement de modules : conventions, namespaces...

- PHP et/ou Smarty pour les templates

- Passionément oriénté objet

- Et bien plus bientot !

 

Ceci est une release précoce, juste pour tâter le terrain et voir si ça fonctionne chez vous !

Oops n'est pas prêt pour la production, doit être testé et doit trouver une license.

Je vous invite cependant à créer des forks et à m'envoyer des pull requests

 

Checkez le projet sur GitHub et dites-moi ce que vous en pensez : https://github.com/alexsegura/Oops

[DevNet]

Bonsoir,

 

Merci pour ce super partage.

 

Question : Qu'apporte Oops de plus que le MVC natif de PrestaShop ?

 

Bien cordialement

[mexique1]

Oops apporte le MVC de Zend Framework, c'est à dire un système normalisé basé sur des conventions simples.

Par défaut le lien entre le controleur et la vue est automatique, ce qui permet de développer des modules complexes rapidement.

C'est surtout au niveau du back office que Oops apporte un plus, en permettant de structurer le code au sein de plusieurs controleurs. Egalement, Zend fournit un module puissant de création, d'affichage et de contrôle des formulaires, directement utilisable !

 

Je fournirai quelques exemples des cas d'utilisation les plus courants d'ici peu

[DevNet]

Merci pour vos précisions. Quand j'aurai un peu de temps je testerai votre pour mettre un pied dans Zend par PrestaShop

 

Bien cordialement

[olea]

Quel est l'intérêt de mapper presta sur zend ?

 

L'un des points forts de presta est justement de s'affranchir d'un framework lourd.

 

 

[DevNet]

Bonjour,

 

Moi juste pour mon information personnelle, je regarderai ça dans la semaine.

Encore merci pour votre partage

 

Bien cordialement

[Captain FLAM]

Quel est l'intérêt de mapper presta sur zend ?

 

L'un des points forts de presta est justement de s'affranchir d'un framework lourd.

Je plussois !!

[mexique1]

Bonjour et merci pour vos avis !

 

Je suis particulièrement intéressé par vos freins à adopter Oops !

 

Belenos > Effectivement, il faut télécharger Zend et Propel. Je ne vois pas vraiment le problème : PrestaShop utilise déjà plusieurs libraires tierces (dans le dossier tools/ également), dont PEAR, qui est un peu l'ancêtre de Zend.

Pour le moment, il faut tout installer séparément... Je travaille sur un meilleur packaging

On peut aussi installer Zend et Propel directement dans l'include_path de l'installation Apache/PHP (sous Linux, généralement dans /usr/share/php).

 

Olea / Captain FLAM > Avez-vous déjà utilisé Zend ?

Ce qui peut être considéré comme lourd dans Zend, c'est la boucle de dispatching dans la partie MVC. Mais avec quelques bonnes pratiques (pas de _forward, pas d'actionStack...) on peut contourner ces lourdeurs.

 

Ok, PrestaShop est "léger", mais dans le cadre du développement d'un "gros" module, celà oblige à réinventer la roue. Dans le back-office, pas de système MVC obligatoire à part créer son propre dispatching dans la méthode getContent() de la classe du module ! La plupart du temps, celà revient à tout coder dans la même classe... Avec Zend, le design des composants du MVC les rend utilisables dans des tests unitaires.

 

Zend est un framework puissant, stable, documenté, avec une grosse communauté. C'est parce que je l'utilise souvent que j'ai voulu offrir la possibilité à ceux qui l'apprécient également pour son confort de développement, de pouvoir l'utiliser au sein de PrestaShop. J'aurais pu utiliser Symfony et Doctrine, mais ceux-cis nécessitent une version de PHP supportant les namespaces.

 

Je vous invite aussi à considérer la partie ORM de Oops... Avez-vous jeté un coup d'oeil au module d'exemple ?

J'ai rapidement mis un exemple de chargement de l'arbre des catégories qui utilise le comportement "nested_set" de Propel, et permet de naviguer dans les catégories d'une manière très naturelle.

Vous pouvez aussi n'utiliser que la partie ORM... J'envisage de créer des outils pour générer des modèles Propel directement utilisables dans vos modules, et ainsi s'affranchir des requêtes "en dur" dans le code. Celà permet de respecter les bonnes pratiques d'emblée, éviter les injections SQL, etc...

 

Encore une fois, merci pour vos commentaires. Vraiment, n'hésitez pas à me faire part de vos doutes à propos de Oops.

Je vous invite à l'installer et à le tester, particulièrement sous Windows (je suis sous Linux), que je n'ai pas pu tester.

[olea]

dans le cadre du développement d'un "gros" module, celà oblige à réinventer la roue.

 

Je ne sais pas ce que tu entends par "gros module".

 

Pour ma part, j'ai déjà développé des fonctionnalités significatives sur Prestashop, sans avoir à réinventer la roue :

le getContent ne me sert qu'à la configuration du module lors de son installation.

Ensuite, toute la fonction se gère par de nouveaux panneaux d'administration, par de nouveaux controller Front Office et parfois par des controller Back Office

Je n'ai jamais rencontré de limitations fortes.

 

Prestashop 1.5 apportera d'ailleurs de nombreuses améliorations pour faciliter le développement :

- smarty dans le back office, pour une meilleure gestion MVC

- le dispatcher de route

- les controller back office

- une API module améliorée

 

 

 

Certes Zend est un bon framework. Toutefois, il nécessite de sérieuses compétences ainsi que des capacités serveurs plus importantes qu'un simple prestashop.

Quitte à mettre un Prestashop sur Zend, pourquoi ne pas utiliser MagenTrucMuche ?....

[mexique1]

Ok, mais tout ce que tu dis à propos du MVC, ce n'est malheureusement pas gravé dans le marbre quelque part

 

La doc explique effectivement comment créer un onglet pour le module (http://doc.prestashop.com/display/PS14/Creating+a+PrestaShop+module), mais dans l'exemple la vue est codée dans le controleur (!), ce qui n'est pas vraiment la meilleure chose à faire, ne serait-ce que pour la lisibilité.

 

Tu me fais d'ailleurs penser que je n'ai rien prévu pour créer des onglets !

 

Par contre, créer des controleurs front-office, je n'ai pas l'impression que ce soit prévu par PrestaShop, si ?

Si le controller n'existe pas dans controllers/, il ne sera pas chargé par l'autoload...

 

Je vais essayer de te faire changer d'avis sur les compétences nécessaires pour utiliser Zend en ajoutant de nouveaux exemples.

Pourquoi comparer Oops à (celui dont on ne doit pas prononcer le nom) ? Je propose simplement un outil supplémentaire. Celà peut paraitre bizarre, mais j'essaie au contraire de simplifier les choses

[olea]

Ok, mais tout ce que tu dis à propos du MVC, ce n'est malheureusement pas gravé dans le marbre quelque part

-> c'est ICI

 

La doc explique effectivement comment créer un onglet pour le module (http://doc.prestasho...estaShop+module), mais dans l'exemple la vue est codée dans le controleur (!), ce qui n'est pas vraiment la meilleure chose à faire, ne serait-ce que pour la lisibilité.

Par défaut, les fichier *.tpl du front sont stockés dans le module lui même.

Il est toutefois possible de les surcharger en en plaçant une autre version dans le répertoire themes/[letheme]/[votremodule]/

La vue BO est effectivement codée dans le controlleur. Le passage en smarty en 1.5 améliore ce point

 

Par contre, créer des controleurs front-office, je n'ai pas l'impression que ce soit prévu par PrestaShop, si ?

En 1.4, il n'est pas d'instancier un controller depuis un module. Il faut, soit le copier dans le répertoire controller, soit laisser dans le répertoire du module un controller à la mode 1.3

En 1.5, ce point devrait également s'améliorer

 

Je vais essayer de te faire changer d'avis sur les compétences nécessaires pour utiliser Zend en ajoutant de nouveaux exemples.

-> pas la peine. Sans formation spécifique, il est impossible de développer sous Zend. C'est un framework puissant mais pas facilement accessible

D'autre part, il demande des ressources serveur plus conséquente qu'un simple prestashop

 

Pourquoi comparer Oops à (celui dont on ne doit pas prononcer le nom) ? Je propose simplement un outil supplémentaire. Celà peut paraitre bizarre, mais j'essaie au contraire de simplifier les choses

-> je suis ouvert à tout nouvel outil et évolution. Mais là je n'en vois pas l'intérêt ni ce que ça va apporter

[DevNet]

@mexique1 : Ce que tu proposes est vraiment sympa de ta part, et zend est un outil puissant. Il fallait oser en tenter le portage sur PrestaShop. J'ai hâte de voir ce que ta proposition a dans le ventre.

 

Pour ceux qui est d'olea et de Captain FLAM, ils sont certes très compétents dans leur domaine à les entendre, mais il leur manque un peu d'humanisme. Quoi que l'on propose, quoi qu'on dise, ils n'auront que des reproches à faire.

 

Je trouve qu'olea et Captain FLAM devraient plutôt user leur énergie à partager leur savoir de leur propre initiative, plutôt que de troller en binôme à chaque fois qu'un membre de la communauté offre un peu de son temps.

 

Il serait bon d'être plus sociable et d’apprécier le geste plutôt que les détails des propositions.

 

Bien cordialement

[olea]

@devnet,

Je suis désolé que tu aies cette impression.

 

Mon intention n'est nullement de faire des reproches et de décourager les initiatives.

 

De part ma formation et mon expérience professionnelle (développeur,testeur, support client, architecte logiciel sur de gros projets), j'estime savoir prendre du recul sur la programmation.

 

Ton post de la semaine dernière n'allait pas dans la philosophie de prestashop. Je me suis donc permis d'apporter des précisions. Je suis prêt à te relire un nouvel article que tu écrirais.

 

Pour ce Post ci, je ne suis pas contre cette initiative. Je m'interroge juste de l'intérêt d'une telle opération.

On peut considérer que prestashop est lui-même un framework, avec ses atouts et ses inconvénients.

Je ne comprends simplement pas l'intérêt de le mapper sur un framework plus complexe.

Mais je suis ouvert a toute explication argumentée.

 

Quant à mon implication dans le projet, je réponds sur le forum suivant mes domaines de compétence et mon temps. Je remonte également de nombreux problème dans le bugtracker : pas directement visible mais cela sert a stabiliser les versions. Enfin, j'ai fait des propositions d'evolution a la team selon les besoins et limitations que j'ai pubrencontrer dans mes développements.

 

 

[Captain FLAM]

Pour ceux qui est d'olea et de Captain FLAM, ils sont certes très compétents dans leur domaine à les entendre, mais il leur manque un peu d'humanisme. Quoi que l'on propose, quoi qu'on dise, ils n'auront que des reproches à faire.

FAUX !!

Fouille un peu mes posts, et tu verras que j'encourage et j'applaudis aux initiatives que j'estime intéressantes (a-t-on encore le droit d'avoir sa propre opinion ... ?)

Merci tout de même de reconnaitre que nous sommes (peut-être ...? ) compétents.

 

Je trouve qu'olea et Captain FLAM devraient plutôt user leur énergie à partager leur savoir de leur propre initiative, plutôt que de troller en binôme à chaque fois qu'un membre de la communauté offre un peu de son temps.

Mais c'est ce que je fais ... !!!!

Par contre, MERCI d'avoir mis le doigt dessus ... j'avais même pas fait gaffe, mais apparemment, olea et moi avons le même regard, la même opinion ...

 

Et puis, ce n'est pas du trollage : je remets sur le feu le problème qui me dérange le plus, et qu'olea (décidément ! ) a posé 2 fois, et auquel, pour l'instant personne n'a répondu :

 

Certes Zend est un bon framework. Toutefois, il nécessite de sérieuses compétences ainsi que des capacités serveurs plus importantes qu'un simple prestashop.

-> pas la peine. Sans formation spécifique, il est impossible de développer sous Zend. C'est un framework puissant mais pas facilement accessible

D'autre part, il demande des ressources serveur plus conséquente qu'un simple prestashop

 

En clair :

 

Avez-vous des tests de performance ? des timings comparatifs (Presta d'origine / avec Oops) ?

 

Paske, moi non plus, je n'arrive pas à voir l'intérêt ... J'aimerai bien comprendre ...

 

Maintenant, je n'empêche personne de tenter des expériences, bien au contraire ...

 

EDIT :

 

Mais ... !! Que lis-t-on sur le site d'olea ??

 

Certifié Zend PHP 5.3 depuis 2011, j’interviens également sur tout autre projet à base de PHP, en particulier basé sur le framework Symfony.

A mon avis, ce gars là, il doit savoir de quoi y parle ...

[mexique1]

Bon les gars, balle au centre

On est tous très passionnés, ça m'étonnerait pas qu'on atteigne le point de Godwin d'ici ce soir

 

Sur les compétences et capacités serveur nécessaires à Zend, je ne suis pas d'accord...

Ok, je n'ai pas de benchmark ou de test de perf, mais le framework je l'ai releasé... hier

Libre à vous de créer des scripts de benchmark et de les partager avec la communauté, ça fera avancer le shmilblick.

J'ai prévu de comparer les perfs, mais c'est loin dans la "roadmap".

 

Je compte ajouter encore de nombreuses choses dans Oops. Mais bon je le fais sur mon temps libre...

 

En ce qui concerne vos critiques, désolé, mais aucun de vous ne justifie non plus ses propos !

Vous dites que Zend est lourd, etc... Mais où sont les preuves ?

Vous rejetez le truc d'entrée, alors que je parie que vous ne l'avez même pas téléchargé. C'est comme dire qu'on aime pas les épinards parce que ça ressemble à de la bouillie extra-terrestre.

 

Bref, on va pas se lancer dans des batailles de citations svp !

 

---

 

Je rebondis néanmoins sur ce que olea a pointé du doigt : on gère les modules avec des onglets !

Je pense donc ajouter quelques changements structurels pour gérer les onglets. Voici ce que je pense faire :

application
|-- mvc
|   |-- preferences
|   | |-- controllers
|   | | `-- IndexController.php => class MyModule_Preferences_IndexController
|   | `-- views
|   |-- foo-tab
|   | |-- controllers
|   | | `-- IndexController.php => class MyModule_FooTab_IndexController
|   | `-- views
|   |-- bar-tab
|   | |-- controllers 
|   | | |-- IndexController.php => class MyModule_BarTab_IndexController
|   | | `-- OtherController.php => class MyModule_BarTab_OtherController
|   | `-- views
|   `-- hooks
|       |-- controllers
|       `-- views
`-- tabs  
   |-- Foo.php         => class MyModule_Tab_Foo extends AdminTab
   `-- Bar.php         => class MyModule_Tab_Foo extends AdminTab

 

Ainsi, chaque onglet aura ses propres controleurs/vues. Qu'en pensez-vous ?

[mexique1]

Développeurs PrestaShop, je vous ai entendus

 

Oops est désormais packagé avec ses dépendances au format ZIP : https://github.com/downloads/alexsegura/Oops/oops.alpha.zip

 

L'installation est très simplifiée, plus besoin d'avoir Git. J'espère que ça vous aidera à l'adopter.

 

D'ailleurs, j'avais "oublié" de committer le package Oops/Db ! Il est dans le ZIP et dans le dépôt, et j'en ai profité pour ajouter un petit exemple d'utilisation de Propel dans le fichier README.

 

A+

[Captain FLAM]

Bon les gars, balle au centre

On est tous très passionnés, ça m'étonnerait pas qu'on atteigne le point de Godwin d'ici ce soir

Je suis sûr qu'avec Zend, Hilter aurait gagné la guerre !!

 

...

 

( :lol: :lol: )

 

Juste pour te donner raison

 

En tout cas, c'est vrai que tu as l'air passionné et que tu maîtrises ton sujet ...

 

Je te souhaite bonne continuation, et j'espère que tu arriveras à faire partager ton amour de Zend à la communauté

[mexique1]

Paix et amour, enfin

J'espère aussi que de nombreuses personnes vont l'adopter !

[mexique1]

J'ai ajouté le support des onglets d'admin pour les modules créés avec Oops

 

On peut désormais profiter du système MVC pour créer un onglet.

 

Jetez un coup d'oeil à la classe Oops_Application_Tab : https://github.com/alexsegura/Oops/blob/master/library/Oops/Application/Tab.php

 

Changement de la convention de nommage bientôt...

[olea]

Quel genre de gros module nécessite ce genre d'environnement ?

 

As-tu un exemple de fonction qu'il est vraiment compliqué de développé sur du prestashop natif ?

[mexique1]

Salut !

 

Finalement, je pense que c'est un ressenti personnel.

 

Personnellement, l'API PrestaShop native ne me satisfait pas. Je la trouve trop permissive, pas assez cadrée, pas assez orientée objet.

Le design des classes ne respecte la plupart du temps aucun des principes fondamentaux de la programmation orientée objet ! Certaines classes abstraites sont au courant de leurs éventuelles implémentations, par exemple.

 

L'API est difficile à comprendre car elle est très hétérogène. La plupart du temps, je suis obligé d'aller lire le code de telle ou telle méthode, car à son nom je ne suis pas certain de ce qu'elle retourne. Trop de méthode qui retournent des arrays directement après un requête SQL, et non des objets, donc impossible à mocker, à tester, etc, etc...

 

Le truc que j'ai ressenti en me plongeant dans PrestaShop, c'est qu'on est quasiment obligé de s'inventer sa propre boite à outils.

Par exemple, rien n'est prévu pour afficher un module dans le corps de la page : ce que propose la doc est un peu du bidouillage... Créer un script PHP quelconque et ajouter soi-même le layout, ce n'est pas vraiment cadré.

 

C'est pour celà que j'ai voulu m'appuyer sur un framework comme Zend.

 

J'avais créé un topic qui n'a pas rencontré de succès pour savoir ce qui était le plus "relou" en tant que développeur : http://www.prestashop.com/forums/index.php?/topic/143149-taches-recurrentes-du-developpeur-prestashop

 

Cependant, je pense que PrestaShop est un très bon soft. C'est pour celà que je ne remets en aucun cas PrestaShop en question via ce framework. Je propose juste un compagnon pour développeurs

 

Comme me disait phrasespot sur le topic anglais, utiliser un tel framework peut s'avérer très utile pour des modules qui nécessitent des changements constants. Il est également utile pour tout type de module à mon sens.

 

J'ai prévu d'ajouter dans Oops de nombreux outils (basés sur Phing ou Zend_Tool) pour développeurs :

- Script en ligne de commande pour :

- initialiser un template de projet Oops

- packager un projet Oops (suppression des tests, génération de la PHPDoc, etc...)

- Script pour générer ses propres modèles Propel

 

Il faut vraiment que j'ajoute un tuto détaillé pour créer une application MVC avec Oops...

[DevNet]

Comme me disait phrasespot sur le topic anglais, utiliser un tel framework peut s'avérer très utile pour des modules qui nécessitent des changements constants. Il est également utile pour tout type de module à mon sens.

 

Je suis entièrement d'accord. La cadence des versions est trop importante pour les projets de développement. Sur une même version 1.4.x, des changements de codes sur des méthodes de classes sont appliqués, ce qui pose des problèmes de compatibilité / rétro-compatibilité pour nos modules. Un module mis à disposition et compatible pour la 1.4.5.1, ne l'ai subitement plus quelques jours après pour la 1.4.6.1, car des bouts de codes des méthodes de classes natives ont été modifiés.

 

C'est à chaque fois une course contre la montre pour les développeurs, et les clients s'étonnent aussi ensuite que les modules sont chers.

 

Moi aussi j'apprécie énormément le code en natif du noyau PrestaShop, qui est de qualité. Mais il est souvent incompatible avec une politique modulaire. Et s'adapte beaucoup à des projets de développement solitaire (overrides et modules dédiés à un client).

 

Un nouveau fork comme zend, pourrait certainement apporter de nouveaux outils plus durables aux développeurs, quelques soient les versions de PrestaShop.

 

Bien cordialement

[mexique1]

Bien sûr que le code de PrestaShop est de qualité.

Sinon, je n'aurais pas créé de framework, j'aurais abandonné de suite.

Niveau sécurité, c'est assez blindé par exemple.

 

Même si je critique le design, j'aime aussi l'aspect "maison" du code de PrestaShop.

C'est parce qu'il est permissif que j'ai pu "incruster" Oops dans PrestaShop, ce que je n'aurais pas pu faire si les mécanismes d'extensions étaient plus restrictifs.

 

Le truc, c'est que la marge de manoeuvre des devs PrestaShop est limitée...

Même si telle ou telle méthode est codée avec les pieds et pas opportune, il est assez difficile pour la team de la supprimer, si elle est utilisée par la plupart des gens...

 

Ha oui, j'oubliais !

L'une des choses que j'aime le moins dans PrestaShop, c'est que la plupart des classes sont concrètes, et n'implémentent pas d'interface. Du coup, impossible d'utiliser le polymorphisme pour avoir, par exemple, plusieurs implémentations de la classe Product. Il faudrait des factory methods partout...

J'envisage d'apporter ça dans Oops aussi, des interfaces. Par exemple, la classe Oops_Db_Product implémentera prochainement Oops_Model_Product, car un produit extrait de la base de données n'est qu'une implémentation d'un produit gérant la persistance...

[mexique1]

Malgré le faible nombre d'adoption, Oops apparait en premier quand on tape "prestashop framework" dans Google

 

http://www.google.fr/search?q=prestashop+framework

 

Espérons que ça va attirer du monde...

[DevNet]

Arf, bon j'avais quelques minutes pour tester ta proposition, malheureusement, juste après avoir copié ce qu'il faut comme tu as mis dans le readme, j'ai un include qui se fait pas :

 

Warning: require_once(/Oops/Application/Bootstrap.php): failed to open stream: No such file or directory in /home/guillaume/.../public_html/prestashop1462.domaine.tld/tools/Zend/Application.php on line 320 Fatal error: require_once(): Failed opening required '/Oops/Application/Bootstrap.php' (include_path='.:/usr/share/php:/usr/share/pear:/home/guillaume/.../public_html/prestashop1462.domaine.tld/tools') in /home/guillaume/.../public_html/prestashop1462.domaine.tld/tools/Zend/Application.php on line 320

 

A+

[mexique1]

Oui, corrigé hier soir : https://github.com/a...1ddf467264d8a6a

 

Peux-tu faire la modif en local et réessayer ?

 

EDIT : Si vous avez un compte GitHub (c'est gratuit), c'est mieux de reporter une issue => https://github.com/a...ura/Oops/issues

[DevNet]

Il faudrait le replacer dans le contexte de PrestaShop car library/Oops/Loader/Autoloader.php ne veut plus rien dire sur GitHub.

 

Le fichier a modifié est certainement [root]/tools/Oops/Loader/Autoloader.php ?

 

Je retrouve ma page de modules sans erreurs. Par contre votre module hellooops n'est pas listé

[mexique1]

Tu as trouvé tout seul

 

Ok, alors vu l'erreur que tu as eue précédemment, ça veut dire que le constructeur de la classe du module a bien été appellée, car ça se produit quand on tente de lancer la Zend_Application.

Donc le module doit bien être référencé.

 

Tu es sûr qu'il n'apparait pas dans la section "fonctionnalités front-office" ?

 

Pour info, ni les hooks ni les onglets ne sont greffés lors de l'installation, il faut le faire manuellement.

 

EDIT : Pour le module démo, ça serait bien qu'il n'y ait rien à faire effectivement...

J'ai prévu de pouvoir configurer les hooks à greffer lors de l'installation dans le fichier application/configs/application.ini

[DevNet]

Ok problème de cache certainement, j'ai bien le module de listé, et il s'est correctement installé.

 

Reste plus qu'à comprendre tous les rouages de Zend et ce qu'il pourrait apporter en plus.

 

Ca serai intéressant que le fork Zend + Routines PrestaShop, soit installés et disponibles sur un module à part. Ensuite tous les modules de développement pures seraient "compatible" avec ce module fork indispensable.

 

En gros, un module fork Zend + Routines PrestaShop gratuit, mis à disposition de tous, et chaque module utilisant se fork devra spécifier ou proposer l'installation du module fork indispensable à son utilisation, s'il n'est pas déjà présent dans les modules.

[mexique1]

Oui, c'est ce que je disais à webbax sur le topic parlant de son propre framework : http://www.prestashop.com/forums/topic/83893-a-venir-le-framework-de-webbax-pour-developper-plus-rapidement-ses-modules

 

Le truc, c'est que j'ai besoin de redéfinir l'autoload... C'est pour celà que j'ai créé un override de la classe ConfigurationCore, car c'est la toute première classe qui est appellée.

 

Pour découvrir rapidement ce que tu peux faire, je te conseille de lire le quick start de Zend : http://framework.zend.com/manual/fr/learning.quickstart.intro.html

 

Sinon, il faut absolument que j'ajoute un Wiki sur GitHub, avec des exemples... Ce week-end

[DevNet]

Pour découvrir rapidement ce que tu peux faire, je te conseille de lire le quick start de Zend : http://framework.zen...tart.intro.html

 

Déjà fait ce matin . Mais pas eu le temps d'essayer le fork avec MySQL.

 

Dans tes exemples, ça serait pas mal d'avoir cette interaction avec la base de données de la boutique.

J'ai réussie à créer rapidement sur ton module d'exemple plusieurs pages de template, en ayant cerné le principe du controller d'index : public function nomdutplAction() { ... }

 

Je suppose d'ailleurs que cet IndexController.php est unique, et que dans l'usage d'un module PrestaShop, on est pas besoin d'autres controllers ?

[DevNet]

Il semblerai aussi que l'accès sur /modules/hellooops/application/configs/application.ini soit disponible. Est-ce normal et / ou dangereux ? Car je suppose qu'avec une interaction MySQL, on y retrouve des éléments importants.

 

Il existe toujours le moyen .htaccess de filtrer l'accès à ce type de fichier, à la racine du module :

<FilesMatch "\.tpl$|\.ini$">
order deny,allow
deny from all
</FilesMatch>

[mexique1]

Enfin, ça bouge

 

Base de données

 

J'ai ajouté un exemple très simple (chargement des catégories de niveau 1) dans le fichier README (sur GitHub) :

 

Example : verify if product #1 belongs to category #42
$product	 = Oops_Db_ProductQuery :: create()->findPk(1);
$category_42 = Oops_Db_CategoryQuery :: create()->findPk(42);
// Get all the categories of a product in one method !
foreach ($product->getCategories() as $category) {
// All standard tree operations available !
if ($category->isDescendantOf($category_42)) {
	// Translated automatically !
	$name = $product->getName();
	echo "Product $name belongs to category #42 !";
}
}

 

Système MVC

 

Justement, l'idée est d'avoir plusieurs controllers, chacun ayant plusieurs vues.

IndexController est le nom du controller par défaut dans Zend, mais on peut le changer.

En fait, c'est le controller qui est appellé quand il n'y a pas de paramètre "action".

 

Je pense vais refondre la structure de l'application pour la structurer comme ça (voir messages précédents) :

- hooks

- preferences

- onglets

 

Fichier de configuration

 

Effectivement, ce fichier est lisible en clair. C'est juste que en INI, Zend le lit par défaut

Tu n'a pas besoin de déclarer tes infos de connexion dedans, car Propel est initialisé avec les constantes du fichiers settings.inc.php

Donc à moins que tu aies 2 bases de données...

 

Mais tu as raison, c'est pas le top...

Il faut que j'ajoute le support de la conf en PHP, dans ce cas il suffirait de déclarer la conf sous la forme d'un array, qui serait retourné par le fichier configuration.php

 

Merci beaucoup pour tes retours !

[DevNet]

Tu n'a pas besoin de déclarer tes infos de connexion dedans, car Propel est initialisé avec les constantes du fichiers settings.inc.php

Donc à moins que tu aies 2 bases de données...

 

Justement, faire la liaison d'un projet Zend existant, sous forme de module PrestaShop, ne serai-ce pas une belle issue ?

 

On peut imaginer un projet utilisant déjà sa base de données et son connecteur via le configuration.ini, et ensuite faire des interactions entre les 2 bdd.

Je pense surtout à des projets de gestion comptable sur zend, il en existe sûrement.

 

Je t'ai fait un article d'annonce sur mon blog aussi : http://blog.dev-net....er-vos-modules/

 

Beau travail

[DevNet]

Par contre l'usage de Propel semble un peu déroutant. La classe Db fera l'affaire

[DevNet]

Pourquoi des fichiers "tpl" pour le view ? On y serait tenté d'y ajouter du smarty .

 

Si je comprends bien il faut sortir le contexte view à la manière d'un echo des contenus rotate html :

 

  	 $out='';
	for($i=0;$i<=10;$i++)
		$out .= "<p>example".$i."</p>";

	$this->view->foo = $out;

[mexique1]

Justement, faire la liaison d'un projet Zend existant, sous forme de module PrestaShop, ne serai-ce pas une belle issue ?

On peut imaginer un projet utilisant déjà sa base de données et son connecteur via le configuration.ini, et ensuite faire des interactions entre les 2 bdd.

 

Oui, en théorie on peut sans trop d'effort faire fonctionner un projet qui tourne déjà sous Zend avec Oops... Bien vu.

 

 

Par contre l'usage de Propel semble un peu déroutant.

 

Ha bon vraiment ? C'est quoi que tu trouves déroutant ?

Justement, moi ce que je trouve déroutant, c'est de devoir écrire les requetes SQL en "dur", ce qui oblige à bien connaitre la base de données. La classe ObjectModel n'est pas satisfaisante à mon sens.

 

On peut générer des requetes complexes avec Propel, sans écrire une seule instruction SQL.

Avec Propel, c'est très naturel : c'est pas cool de pouvoir charger toutes les catégories d'un produit aussi simplement ?

$product->getCategories()

 

Cependant, je n'ai pas établi toutes les relations dans le schema de base de données, ce qui fait que toutes les méthodes n'ont pas été forcément générées.

[mexique1]

Pourquoi des fichiers "tpl" pour le view ? On y serait tenté d'y ajouter du smarty .

 

Hé bien, c'est ce qu'il faut faire !

En fait, Oops supporte à la fois PHP et Smarty, selon l'extension du fichier.

Pour le moment, c'est Smarty qui est chargé en priorité.

 

Par exemple, quand tu affiches une vue "index", si le fichier "index.tpl" existe, il sera interprété en Smarty, sinon c'est le fichier "index.phtml" qui sera rendu.

 

[mexique1]

Je t'ai fait un article d'annonce sur mon blog

 

M.E.R.C.I

[DevNet]

Dans l’administration smarty n'est pas chargé ?

[mexique1]

C'est une question ? Chez moi ça marche, pas chez toi ?

[DevNet]

C'est une question ? Chez moi ça marche, pas chez toi ?

Autant pour moi, ça fonctionne.

 

Donc voilà une réponse que l'on peut aussi donner à olea : On peut utiliser smarty dans le back-office avec Oops sans déranger le reste

[mexique1]

Ma foi... Il me semble que ça fonctionne même en natif.

 

J'ai vu ton fork et ton pull request, bien vu, merci

[olea]

Donc voilà une réponse que l'on peut aussi donner à olea : On peut utiliser smarty dans le back-office avec Oops sans déranger le reste

 

Ca ne m'étonne pas...

Une fois qu'on a démarré Zend on a accès à toutes ses fonctions, dont la gestion smarty

Il faut juste noter que les panneaux back-office actuels n'utilisent pas smarty. Il faut tous les réécrire pour utiliser smarty : c'est ce qu'à fait la team pour la 1.5

[mexique1]

Une fois qu'on a démarré Zend on a accès à toutes ses fonctions, dont la gestion smarty

 

Pas du tout ! Zend n'implémente pas Smarty

 

http://framework.zen...ripts.templates

 

Ce qui permet de gérer Smarty dans Oops ce sont ces deux classes :

- Oops_View_Smarty : responsable du rendu des vues Smarty, implémentation de Zend_View inspirée de la doc Zend.

- Oops_Controller_Action_Helper_ViewResolver : responsable du choix du template à rendre (*.tpl ou *.phtml)

 

Je ne comprends pas... Vous dites que vous n'avez jamais pu utiliser Smarty dans le back-office d'un module ?

Je l'ai déjà fait en natif, j'en suis sûr.

[olea]

Pas du tout ! Zend n'implémente pas Smarty

Effectivement, ma phrase est mal tournée.

Je voualis dire, dès qu'on a réussi a démarrer un Zend, on a toutes les briques pour faire tout ce qui peut se construire à partir de Zend.

 

Je ne comprends pas... Vous dites que vous n'avez jamais pu utiliser Smarty dans le back-office d'un module ?

Je l'ai déjà fait en natif, j'en suis sûr.

Dans presta, le front office est géré en smarty (les controller/frontController), mais pas le back office (les AdminTab)

Depuis un module, on sait gérer du smarty pour le front office (avec d'ailleurs un système de surcharge de tpl du module par des tpl qui seraient situés dans le thème). On sait aussi gérer des AdminTab, mais par définition, sans smarty

 

En 1.5 cela évolue avec le back offcie qui supportera une meilleure gestion MVC

[mexique1]

Ok, oui les AdminTab livres ont tous le code HTML codé direct dans la classe PHP.

Mais en fait tu peux tout a fait utiliser Smarty.

[mexique1]

Salut !

 

J'ai changé (définitivement, j'espère) la structure des répertoires pour plus de clarté : hooks, preferences et tab-* pour les onglets.

 

J'ai également complété le module "Hello, Oops" avec le traitement d'un formulaire, et il y a désormais un wiki.

 

https://github.com/alexsegura/Oops/wiki

[DevNet]

Bonjour,

 

Il sert à quoi le répertoire db de l'archive ? Est-elle à jour pour que je la teste à nouveau ?

 

A+

[mexique1]

L'archive est à jour oui.

 

Le répertoire db/ sert à la génération des modèles Propel en mode développement.

Dans un futur proche, je pense qu'il servira aussi à créer des modèles pour les modules.

Il n'est pas packagé dans l'archive (tu confirmes ?), et on le trouve uniquement en clonant le dépôt.

 

J'ai ajouté rapidement une page au wiki sur les contribution qui explique vaguement l'utilisation de ce répertoire

 

https://github.com/alexsegura/Oops/wiki/Contribute

[DevNet]

Je vais tester à nouveau l'archive, mais sans propel, ça me parle vraiment pas ce truc

[mexique1]

Ok, j'espère que l'exemple de traitement de formulaires va te plaire alors

[mexique1]

Je suis en train de réfléchir à ce que je pourrais ajouter dans Oops prochainement.

 

Le fait est que je développe Oops en même temps que je réalise un site sous PrestaShop, donc les fonctionnalités ajoutées sont en fonction des besoins du site !

 

Actuellement, je bosse sur un module qui effectue une requete AJAX vers lui-même.

Je n'ai pas l'impression qu'il y ait quoi que ce soit de prévu pour ça dans PrestaShop... Je me trompe ?

Y a-t-il quoi que ce soit pour invoquer son module via AJAX ?

 

Pour le moment, j'ai fait un truc un peu bidon qui lance un HooksController avec une action spécifique...

Quels sont vos "patterns" pour utiliser AJAX au sein de vos modules ?

 

 

 

Sinon, quelles sont selon vous les choses les plus importantes à ajouter ?

 

- Traductions

- Namespace automatique pour sauvegarder la configuration des modules

- Auto-installation des hooks & onglets

- Surcharge des templates dans le theme

[Broceliande]

Je suis en train de réfléchir à ce que je pourrais ajouter dans Oops prochainement.

 

Le fait est que je développe Oops en même temps que je réalise un site sous PrestaShop, donc les fonctionnalités ajoutées sont en fonction des besoins du site !

 

Actuellement, je bosse sur un module qui effectue une requete AJAX vers lui-même.

Je n'ai pas l'impression qu'il y ait quoi que ce soit de prévu pour ça dans PrestaShop... Je me trompe ?

Y a-t-il quoi que ce soit pour invoquer son module via AJAX ?

 

Pour le moment, j'ai fait un truc un peu bidon qui lance un HooksController avec une action spécifique...

Quels sont vos "patterns" pour utiliser AJAX au sein de vos modules ?

 

 

 

Sinon, quelles sont selon vous les choses les plus importantes à ajouter ?

 

- Traductions

- Namespace automatique pour sauvegarder la configuration des modules

- Auto-installation des hooks & onglets

- Surcharge des templates dans le theme

 

Pour ce qui est des requetes ajax d'un module vers un traitement qui lui est propre, perso je crée un controller (qui etend la classe FrontController), qui traite les données get/post et lui même instancie le module, puis appelle les méthode requises.

C'est assez presta like à mon sens , mais dans ton architecture là je sais pas car bien que piqué d'intérêt , je n'ai pas eu le temps de tester ta contrib.

 

Ce que je note au passage , c'est que la classe module , à l'instar de la classe Db , possède une méthode statique permettant d'instancier un module via son nom , un truc genre

 Module::getInstanceByName('monmodule') .

 

Ceci dans un controller reste suffisamment propre

Module::getInstanceByName('monmodule')->maMethode()

 

Je doute que quelque modification de ce type d'appel soit nécessaire , car ça respecte mvc, et c'est natif presta .

 

Dans mes controllers , je m'en sers parfois aussi pour lier les translations à mes modules :

 

$monModule = Module::getInstanceByName('monmodule');

$maTrad = $monModule->l('machaine');....

 

ce qui peut être utile pour un retour ajax traduit ...

 

Sinon, quelles sont selon vous les choses les plus importantes à ajouter ?

 

- Traductions

- Namespace automatique pour sauvegarder la configuration des modules

- Auto-installation des hooks & onglets

- Surcharge des templates dans le theme

 

Là le namespace semble une fonctionnalité intéressante. La surcharge moins car c'est déja implémenté en natif , et que peut on apporter de plus à un tpl qu'un autre tpl ?

L'auto install des onglets n'est pas un gros challenge non plus , pour les hooks ça implique forcément une override de tel et tel controller et là j'ai jamais trouvé de solution universelle , enfin si une , mais qui a ses restrictions, à savoir que quelque soit le hook créé à la volée , les variables smarty attendues en params doivent être réassignées, ce qui dépend du hook.

Ca ne fonctionne donc que pour les hooks de modules auto suffisants...

 

Mais ce topic est de plus en plus intéressant

[mexique1]

Salut !

 

Merci énormément pour tes réponses nocturnes

 

Ajax

 

Tu sais quoi ? J'ai abordé le problème de la même manière.

En fait l'idée est de créer un script (que j'ai nommé ajax.php) dans le dossier du module.

Ce script récupère effectivement une instance du module via la méthode que tu décris, et intialise la requête afin d'appeller un controller spécialisé dans les requêtes ajax.

 

On peut également imaginer restreindre l'accès à ce script aux requêtes AJAX uniquement, en effectuant un filtrage sur le header X_REQUESTED_WITH, et ainsi éviter d'éventuelles attaques DDOS.

 

Je me demande par contre si un controller est suffisant pour gérer toutes les requetes ajax de tous les hooks d'un module...

 

Fonctionnalités

 

Là le namespace semble une fonctionnalité intéressante. La surcharge moins car c'est déja implémenté en natif , et que peut on apporter de plus à un tpl qu'un autre tpl ?

 

Ok, les namespaces lors de la sauvegarde via la classe Configuration ça me semble aussi indispensable.

Je pensais même donner l'accès en écriture aux composants back (preferences, tabs) et uniquement en lecture aux composants front (hooks).

 

Je pense l'implémenter dans la philosophie Zend au moyen d'un objet Zend_Config (un genre de tableau survitaminé), qui fera en quelque sorte office de proxy.

 

Concernant la surcharge des templates, ça ne peut pas fonctionner "direct" dans Oops, car celui-ci utilise son propre système de vues. La surcharge est possible en natif à condition d'utiliser la méthode display() de la classe Module, qui vérifie si un template existe dans le thème. Or, Oops ne l'utilise pas. Mais c'est assez simple à implémenter.

 

L'auto install des onglets n'est pas un gros challenge non plus , pour les hooks ça implique forcément une override de tel et tel controller et là j'ai jamais trouvé de solution universelle , enfin si une , mais qui a ses restrictions, à savoir que quelque soit le hook créé à la volée , les variables smarty attendues en params doivent être réassignées, ce qui dépend du hook.

Ca ne fonctionne donc que pour les hooks de modules auto suffisants...

 

Excuse-moi, je n'ai pas bien compris ce dont tu parles par rapport à l'override d'un controller ?

 

Par contre, tu parles de modules auto-suffisants... Tu veux dire que dans certains cas, tu peux avoir besoin de créer des modules qui sont des dépendances d'autres modules ?

Intéressant ! Ca pourrait être pas mal à ce moment là de réfléchir à comment exposer une API pour les modules...

 

Encore merci, et si tu trouve un petit moment pour tester Oops...

[mexique1]

Quelques nouveautés :

• Support de l'extension *.php pour les templates (+ secure)
  
• Support de l'override des templates dans le thème (on peut même overrider un template PHP par un template Smarty et vice-versa)
  
• Installation des hooks via fichier de configuration
  

[DevNet]

Salut mexique1,

 

C'est un cadeau de Noël ?

[mexique1]

En quelque sorte... C'est cadeau, ça, c'est sûr

 

Dommage qu'il n'y ait pas grand-monde devant le sapin

[DevNet]

C'est peut-être une période creuse en ce moment. Je pense qu'à la mi-janvier des retours vont se faire.

[mexique1]

Salut,

 

J'ai fait une mise à jour consistante, qui fixe pas mal de problèmes identifiés récemment.

 

Quelques nouveautés également :

• Support de la configuration, pas de namespaces finalement
  
• Support des traductions avec Zend_Translate
  
• Rendu des templates "standard" du thème (category.tpl, product.tpl, etc...)
  

Ca commence à être bien intégré donc on peut ajouter à peu près toutes les ressources Zend standard, comme les logs, les traductions...

 

Je suis aussi tombé sur un projet qui est un support de Twig sous Zend, et qui semble présenter une meilleure technique pour "switcher" le moteur de template. Ca pourrait permettre d'avoir Twig sous PrestaShop

 

J'ai aussi entièrement refait le wiki pour plus de clarté !

 

A+

[DevNet]

Merci !

 

Si j'ai le temps je regarderai la semaine prochaine

 

A+

[mexique1]

J'ai commencé à m'attaquer au thème du site sur lequel je travaille.

Cependant, les mécanismes pour construire un thème ne me satisfont pas.

 

Le gros point noir est la template method run() de la classe FrontControllerCore, un peu trop couplée avec le design 3 colonnes.

J'ai besoin d'avoir un design avec 1, 2 ou 3 colonnes selon la page, et celà n'est pas possible nativement.

 

Donc je pense que je vais ajouter quelque chose dans Oops pour supporter les layouts.

Celà permettra d'éviter d'ouvrir une div dans un template et de la fermer dans l'autre, et ouvrira la voie pour un design mobile.

[Spir]

Salut,

J'arrive un peu tard. Mais vous êtes fou?

J'aimerai avoir un exemple de module qui nécessite l'utilisation de Oops.

J'ai fait pas mal de module pourtant j'ai jamais resenti le besoin d'utiliser un framework. Moi aussi avant PS j'utilisais (et je continue d'utiliser) des frameworks pour mes projets.

Pour ce qui est du front oui pourquoi pas mais ca représente pas mal de boulot.

[mexique1]

Salut, enfin du monde

 

Je n'ai pas d'exemple précis en tête, en tout cas personnellement j'utilise Oops pour tous mes modules...

 

Encore une fois, c'est un peu les goûts et les couleurs. Le créateur de PHP lui-même est anti-framework (http://toys.lerdorf.com/archives/38-The-no-framework-PHP-MVC-framework.html), a-t-il raison, a-t-il tort, je ne sais pas.

 

Ce qui est proposé par PrestaShop ne me convient pas, je propose donc une alternative.

 

J'ai choisi Zend car en dehors du MVC c'est une boîte à outils incontournable.

Quand on veut faire du RSS, attaquer des services web, écrire du PDF, utiliser la recherche Lucène, ... Zend apporte une solution élégante et puissante.

 

Même pour ce qui est du back-office, Oops peut grandement faciliter les développements: tu peux afficher et valider des formulaires en une ligne de code, et en prime ils seront skinnés automatiquement.

 

Je vais prochainement publier des modules gratuits basés sur Oops, pour montrer ce qu'on peut faire.

[Spir]

Sur l'article de Rasmus que tu pointes il explique juste le point noir des frameworks : leur empreintes. Et celle de Zend est assez conséquente. Je n'ai plus l'image montrant toute les class loader pour un simple echo "hello world"; mais c'est assez impressionnant. Un outil comme PS est créé sans l'utilisation de framework pour justement éviter de charger des lignes de code qui ne seraient pas utilisées.

Bref je reste très sceptique. Même si j'aime utilsier des ORM et autres outils qu'on trouve dans les Frameworks.

 

Si tu veux faire du PDF t'as la class PDF de Prestashop. Dans un module j'ai eu besoin d'écrire dans un PDF déjà généré, il m'a suffit par exemple de rajouter la librairie FPDFi dans tools et voilà!

 

Bref je suis sceptique mais je suis d'accord sur le fait que le système de module pourrait avoir une API amélioré. Je crois que sur la 1.5 il y a un travail la dessus. De là à utiliser un framework, c'est un peu bourrin.

 

Pourquoi ne pas plutot faire un générateur de module a partir d'un framework?

[mexique1]

C'est toujours le reproche qui est fait aux frameworks: pour des trucs simples, c'est too much.

 

Mais on ne peut pas non plus dire que PrestaShop soit simple: des milliers de fichiers, des centaines de fonctionnalités, un mécanisme de plugins (les modules), bref une véritable plateforme. Ce n'est pas un "hello world"

 

On ne peut décemment pas gérer tout ça avec du code procédural: c'est le cas, PrestaShop est tout de même plus ou moins bâti à base de classes.

 

Mais l'architecture de PrestaShop a ses limites. Ok, c'est ouvert à l'extension, mais ce n'est pas fermé à la modification.

[mexique1]

Petite remarque: j'ai bien l'impression que PrestaShop se rapproche de Zend, enfin, plutôt d'une architecture MVC digne de ce nom...

 

Une preuve parmi d'autres, le Dispatcher (enfin) ajouté en version 1.5:

- PrestaShop : http://www.prestashop.com/forums/topic/135108-le-dispatcher/

- Zend : http://framework.zend.com/manual/fr/zend.controller.dispatcher.html

 

Le Dispatcher est dans Zend depuis la version 1.0, qui date d'il y a plus de 4 ans !

Normal, car il s'agit d'un élément incontournable, qu'on retrouve aussi dans Symfony par exemple.

 

Pourquoi ? Car il n'y a pas 36 manières de faire correctement du MVC en PHP, et tous les grands frameworks tendent vers la même chose.

[Spir]

Personnelement j'utilise des framework a faible empreinte comme CodeIgniter, FuelPHP. Chez Prestashop il y a des developpeurs qui on travaillé sur des frameworks comme Kohana auparavant. C'est pour cette raison qu'on trouve le dispatchers par exemple. Et puis on est plusieur développeur à avoir demandé ce genre de fonctionnalités (n'avoir que un fichier PHP dans www + les fichiers statics (css, js et images) afin d'eviter a avoir des codes plus ou moins redondant (cf les fichiers à la racine). Les frameworks apportent leur part de bonne pratique certes mais ils sont parfois lourd. L'utilisation parfois lourde des ORMs pour un module Prestashop ne me semble pas justifié puisque généralement les modules utilisent la table configuration ou une table "custom". Mais pourquoi dans le cas d'un module complexe. Encore une fois je suis perplexe.

[mexique1]

des framework a faible empreinte

 

Mais c'est quoi que tu appelles "faible empreinte" ? Empreinte mémoire ?

Quand j'entends ça, je pense plutôt faible couplage avec le framework, mais c'est pratiquement impossible en PHP, tu devras forcément implémenter au moins une interface. Donc tu es lié au framework que tu utilises.

Le seul framework qui est vraiment "léger", c'est le framework Java Spring

 

 

Chez Prestashop il y a des developpeurs qui on travaillé sur des frameworks comme Kohana auparavant. C'est pour cette raison qu'on trouve le dispatchers par exemple.

 

Ok.

Mais alors à la fin on va trouver dans PrestaShop la même architecture que dans les "grands" frameworks PHP ?

Ce n'est pas une démarche très constructive, et ça ne respecte pas la règle du Don't Repeat Yourself.

Si quelque chose existe déjà en open-source, il ne faut pas le refaire, mais l'améliorer.

[olea]

Ne pas oublier que Prestashop n'est pas un framework permettant de faire n'importe quelle application mais bien une application en elle-même, qui a besoin d'un socle de fonctionnalité de base pour pouvoir être développée.

[Spir]

Mais c'est quoi que tu appelles "faible empreinte" ? Empreinte mémoire ?

Quand j'entends ça, je pense plutôt faible couplage avec le framework, mais c'est pratiquement impossible en PHP, tu devras forcément implémenter au moins une interface. Donc tu es lié au framework que tu utilises.

Le seul framework qui est vraiment "léger", c'est le framework Java Spring

L'empreinte c'est la mémoire, les lignes de code chargé pour faire ce que tu veux faire. Des framework comme Zend ou Symfony on tendance a chargé trop de code.

Regarde ca :

http://www.ruilog.com/blog/view/b6f0e42cf705.html

Ok le benchmark du hello world est discutable.

 

 

Ok.

Mais alors à la fin on va trouver dans PrestaShop la même architecture que dans les "grands" frameworks PHP ?

Ce n'est pas une démarche très constructive, et ça ne respecte pas la règle du Don't Repeat Yourself.

Si quelque chose existe déjà en open-source, il ne faut pas le refaire, mais l'améliorer.

Arrête de dire "grands" frameworks PHP aujourd'hui on retrouve le motif MVC, les systèmes de route, le HMVC les ORM dans quasiment tout les frameworks (si ce n'est pas out of the box il existe des libs pour le faire en générale).

Prestashop utilise juste a sa manière les bonnes pratiques qu'on peut trouver dans un framework. Mais un framework ne fait pas de ecommerce et prestashop n'est pas fait pour faire autre chose que du ecommerce donc si c'est dans une démarche constructive et si ca respecte le DRY et le KISS (tant qu'a sortir des gros mots allons y!)

 

Le problème de Magento c'est justement ca! C'est une usine a gaz et c'est basé sur Zend…

[shagshag]

Je ne pense pas que l'idée de départ soit de remettre en question Prestashop est son code, après ça a divergé.

 

L'idée d'aider le développement de module, qui est lié à PS mais pourrait être désolidarisé au maximum, n'est pas mauvaise. Par contre ça implique que le développeur connaisse PS et Zend pour ne pas réinventer la roue dans un sens ou dans l'autre. Il faut aussi que le serveur tienne la route, certains ont du mal avec que PS alors si Zend se charge en plus c'est mort. De toute façon il y aura duplication de code donc perte de performance.

 

Faut pas oublier aussi que le public de PS n'est pas le même que celui de Magento, les budgets en hébergement non plus. Beaucoup de boutique PS sont sur des petits mutualisés. Là mes modules Oops, on oublie.

 

"la règle du Don't Repeat Yourself" (c'est plutôt un code non ?) ne s'applique pas ici. PS et Zend sont deux choses différentes prévues pour faire des choses différentes. Que certaines fonctionnalités de Zend soit (et seront) refaites dans PS mais la majorités des fonctions de Zend sont inutiles à PS (je parle du coeur, pas des modules).

[shagshag]

Si j'en crois ça : http://framework.zend.com/manual/fr/requirements.introduction.html Zend c'est minimum PHP 5.2.4, Prestashop c'est mini PHP 5.0 (5.1 pour la 1.5 je crois) donc pas possible de mettre un module Oops en vente sur addons par exemple, ce sera que pour du développement spécifique. ça limite beaucoup

[mexique1]

J'en ai marre de me justifier...

 

Le truc, c'est que je pensais aider en partageant gratuitement et librement ce que j'ai fait.

 

Au lieu de ça, on me balance une armée de trolls poilus sur 4 pages, plus ou moins basés sur des légendes urbaines (Zend c'est lourd, Magento c'est une usine à gaz, les Macs ça plante jamais...).

 

Désolé, mais j'ai beau parcourir les forums et Google, je vois peu d'initiatives de ce genre pour PrestaShop !

Ce que je constate plutôt, c'est que la plupart des modules intéressants (voire indispensables) sont payants et closed-source, ce qui n'aide pas trop à améliorer l'ensemble de la plateforme.

Moi j'ai l'impression qu'il n'y a pas vraiment d'esprit communautaire autour de PrestaShop, c'est plutot chacun sa merde...

 

Vous avez tous l'air de croire que je n'aime pas PrestaShop... mais alors pourquoi je ferais ça ???

 

---

 

J'aurais plutot préféré voir sur ce thread des conseils pour faire avancer le schmilblick, du genre de ce que tu pointes shagshag :

 

 

Si j'en crois ça : http://framework.zen...troduction.html Zend c'est minimum PHP 5.2.4, Prestashop c'est mini PHP 5.0 (5.1 pour la 1.5 je crois) donc pas possible de mettre un module Oops en vente sur addons par exemple, ce sera que pour du développement spécifique. ça limite beaucoup

 

Déjà pointé du doigt sur le thread anglais, je suis ouvert aux propositions pour le packaging.

En gros, il y a deux solutions: soit les modules embarquent Oops (il suffit de mettre Zend + propel + Oops dans un dossier /library dans le module !), soit Oops est installé dans /tools. Celà implique effectivement une large adoption.

 

En ce qui concerne la version mini pour Zend, ça dépend des libs que tu utilises : par exemple, si tu utilises Zend_Json, il utiliser l'extension native si disponible, sinon il fallback sur une implémentation maison.

 

Les modules principaux de Zend fonctionnent avec une install PHP standard !

Certains modules très spécifiques nécessitent des extensions PECL, genre la base de données DB2, le cache APC... brefs des trucs pas indispensables.

 

 

---

 

Ce que j'aimerais que Oops devienne en fait, c'est un peu un laboratoire d'idées, indépendant de la team PrestaShop, qui peut ainsi continuer à stabiliser et améliorer la plateforme.

La team PrestaShop pourrait alors intégrer nativement ce qui s'en dégage...

 

D'ailleurs, dommage qu'on ait pas encore eu l'avis d'un des membre de la team PrestaShop... C'est pas faute de faire des appels du pied

 

 

Bref, j'ai intégré Zend dans PrestaShop

[Spir]

Moi je te donne mon avis sur l'idée. Je trouve que c'est prendre une machine de guerre pour écraser une fourmi.

Tu prends une initiative intéressante et je ne t'en blame pas c'est juste que je trouve ca démesuré. J'aurai plutot vu comme je le disais plus haut un outil pour générer des modules. De cette manière tu y gagnes sur tout les front: tu a un module facile a maintenir et tu as un code léger.

[DevNet]

Moi je te soutiens fermement mexique1, même si le temps me manque pour tester à nouveau tout ça.

 

C'est un vrai défi ce que tu as fait, et je pense qu'une ressource comme toi ne doit pas t'arrêter à ces remarques. Ton intention est noble, car elle symbolise l'ouverture de nouvelles possibilités.

 

Certains ont du mal à le concevoir, mais si son système permet d'intégrer des projets Zend déjà existant à PrestaShop, sans avoir à tout recoder, et juste le minimum, je trouve que son projet est super intéressant.

 

Big Up mexique1 !

[Carl Favre]

Bonjour mexique1,

 

Merci pour ta contribution c’est fort sympathique à toi de mettre ton outil à la disposition de chacun et gratuitement.

 

Pour ce qui est des arguments sur l’utilité ou non, chacun à pu s'exprimer, mais il ne faudrait pas aller jusqu’à décourager les initiatives louables comme celle-ci, ça serait un peu bête

 

D’ailleurs, rien ne vous empêche de créer un topic dédié sur la pertinence d’utiliser un framework ou non.

[jeckyl]

Bonjour,

 

Personnellement, n'étant pas un développeur stricte et surtout non expert. Ce que j'aime actuellement dans Prestashop c'est justement sa simplicité de codage qui permet de prendre en main la solution très très rapidement.

 

Après ce que j'ai pu constater sur certains modules codé par certains professionnels du codage, c'est qu'il ne cherche pas à utiliser ce qui existe dans Prestashop mais à toujours refaire la roue comme on leur a appris à l'école et du coup on se retrouve avec une flopée de module qui ne respecte rien et son non évolutif. J'en ai un qui qui perd ses traductions à chaque fois que je traduit autre chose sur mon site, un comble.

 

Je ne connais pas Zen ou cake ou les autres, mais ce que je sais c'est que je n'ai pas pris Magento pour justement ce type de chose. Trop complexe car je ne suis pas un développeur. Alors que Prestashop si on sait lire un minimum, on comprends.

 

Après l'idée de renforcer Prestashop avec des surcouche de produit annexes, cela me fait penser à notre bon vieux processeurs x86 qui engrange tout et son contraire depuis des années pour satisfaire des modes.

 

Donc de mon point de vu de non dev, je suis sceptique, mais par contre je reconnait que le boulot est immense et te félicite pour cela.

[mexique1]

Merci à vous. Je boudais pas, hein

 

J'ai lancé le sujet dédié, ça allègera ce thread : http://www.prestashop.com/forums/topic/152393-pourquoi-ne-pas-sappuyer-sur-un-framework/

 

 

Je ne connais pas Zen ou cake ou les autres, mais ce que je sais c'est que je n'ai pas pris Magento pour justement ce type de chose. Trop complexe car je ne suis pas un développeur. Alors que Prestashop si on sait lire un minimum, on comprends.

 

C'est vraiment bizarre, parce que au final c'est l'inverse...

Dans PrestaShop, t'es tout le temps en train de lire le code, parce que les APIs ne sont pas homogènes.

Dans Zend, il y a une logique globale, qui fait que à peu près toutes les classes s'utilisent de la même manière.

La plupart du temps, j'ai pas vraiment besoin de regarder la doc ou le code, ça coule de source.

 

Comme disait l'autre, c'est "simple in a complex way". (Steve Jobs, je crois)

 

Evidemment, si tu ouvres les classes de Zend, ça peut paraitre complexe.

Mais cette complexité ne se ressent pas lorsque tu utilises les classes !

 

En fait, c'est compliqué à l'intérieur, mais simple à l'extérieur...

 

Voici le code nécessaire pour afficher un formulaire...

Ne me dis pas qu'il ne se lit pas comme du français !!!

 

$form = new Oops_Form_Admin();


$text = $form->createElement('text', 'name', array(
   'label'   => 'Name',
   'description' => 'Only alpha-numeric text allowed',
   'required'  => true
));

// Add a submit element with the "button" CSS class
$submit = $form->createElement('submit', 'Save', array(
   'class' => 'button'
));

$form->addElement($text);
$form->addElement($submit);


echo $this->form;

[Jovicyr]

Bonjour mexique1,

 

Je viens de lire avec attention tout ce thread. Tu en es où de ce développement ?

 

Bien à toi,

[mexique1]

Salut,

 

Le statut est stable (on peut utiliser toutes les classes de Zend, le MVC fonctionne, l'essentiel des modèles pour l'ORM ont les bonnes relations).

 

Cependant, le développement est plus ou moins arrêté, car sur la partie MVC, PrestaShop 1.5 fixe plus ou moins le problème, et puis, celà n'a pas suscité un très vif intérêt malgré une vingtaine de téléchargements et une dizaine de followers

Le problème c'est que j'ai pas vraiment de retours...

Je suis également assez occupé pour finaliser le site que je fais sous PrestaShop !

 

D'autre part, j'ai un peu changé mon fusil d'épaule, car je voudrais que le framework soit utilisable par tous, et que les développeurs de modules puissent soumettre sur addons. Comme je le disais sur la mailing-list, dans le futur ça va plutôt s'orienter sur un outil de scaffolding, et se concentrer sur la partie ORM / formulaires.

 

Voilà voilà.