Retour d’expérience sur FLOW3 et Django

Par défaut

Cet article n’a pas pour objectif de comparer ces deux frameworks et il ne prétent pas être une synthèse complète et objective. J’ai tout simplement passé un peu de temps sur chacun d’eux et ceci est mon ressenti vis à vis de ma montée en compétence.

Intro

Pour moi la découverte de nouvelles technos passe souvent par un nouveau projet. J’ai besoin d’une idée à réaliser pour pouvoir mettre en pratique ce que j’ai envie d’essayer. Etant freelance il n’est pas facile de consacrer du temps à l’autoformation. Peu de client souhaite payer votre montée en compétence et en général on évite de s’aventurer répondant à des marchés portant sur des technos non maitrisées. Bref, à chacun sa stratégie.

Ainsi donc il me faut un projet perso à réaliser. Une fois trouvé, je me retrouve généralement dans les dynamique suivante : 50% de ma motivation pour l’idée en elle même du projet et 50% pour la techno à tester.
Quand je dis techno, c’est au sens large : ça peut être un langage, un framework, un composant technique, un environnement ou même un concept.

Ces derniers temps il me trottait dans la tête une envie de remettre sur pied un vieux projet. Les idées se bouscoulent, tout ça tombe bien, j’ai très envie de tester FLOW3, un nouveau framework PHP développé par la communauté TYPO3.

FLOW3

Venant de faire un peu de Zend Framework (v1) et en étant assez déçu, je me mets donc à la recherche d’infos et de retours sur ce nouveau framework qui semble bien conçu et bourré de concepts sympas. Slideshare est rempli de présentations toutes plus convaincantes les unes que les autres.

FLOW3 est un framework MVC composé d’un tas de truc qui font brillées les yeux des développeurs php (surtout s’il vient du milieu TYPO3) : AOP, Injection de dépendance, Doctrine, annotations, FLUID (moteur de template), cache, sécurité, etc. A cette époque nous en somme à la version 1.0.

Bref je ne vais pas plus développer et simplement dire que j’ai été déçu.
Ce framework est encore jeune et même si ce qui est documenté est bien documenté il y a, d’une façon générale, encore un énorme manque de ressources. Soit, pour résumer :

  • La doc est loin d’être finie et je trouve que souvent, la mise en pratique de ce qu’on vient de lire n’est pas toujours évidente. Tout est tellement découpé et conceptualisé qu’il faut manipuler énormément de chose pour faire parfois un truc simple
  • Le framework est jeune et du coup il y a des changements importants qui sont encore opérés (1.0 => 1.2 : authentification, gestion des packages, models / repository, i18n). 
  • Peu d’exemple et peu de code disponible : le fait d’avoir quelques projets libres utilisant une techno est facteur d’inspiration. On (je ?) débloque souvent une situation en m’inspirant de ce qui a été fait. Exemple d’un manque : l’i18n (mais la doc a été améliorée depuis il me semble).
  • Peu de modules / extensions / plugins : autre type d’authentification, autre type de bdd, éditeur wysiwyg, bootstrap, captcha, compresseur css/js, etc, etc
  • Une petite communauté ce qui veut dire avoir de la patience : les personnes pouvant vous répondre ne sont pas nombreuses
Alors voilà, l’aventure FLOW3 s’arrête là pour le moment. Il y a de forte chance que j’y revienne d’ici quelques temps car ce framework est vraiment prometteur … mais aussi parce que j’avoue aimer tout ce qui se rapproche à la communauté TYPO3 (les développeurs, l’esprit qui se dégage des projets, la façon dont la communauté interagit).
Très modeste contribution : FLOW3.Facebook : un package que j’ai réalisé permettant l’authentification via Facebook.

Django

Deux copains venant eux aussi de PHP me disaient fréquemment de jeter un oeil sur Django, que c’était vraiment top. Mon projet se réalisant avec eux et voyant que je ne suis pas très productif sur FLOW3, je me décide à m’y essayer. Petite info au passage, je n’ai jamais fais de Python.

Django est un framework Python qui met particulièrement l’accent sur 6 points : l’ORM, l’interface admin, la gestion des url, le système de template, la gestion du cache et l’internationalisation. Ca fait un tas d’autre chose mais, globalement, c’est sur ces points que le focus est mis.

Me voilà donc parti. Premier constat, c’est surprenant d’efficacité et de simplicité, en peu de temps j’arrive à recoder ce que j’ai fait sous FLOW3. Bref : « Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design. »

Vous l’aurez compris, Django m’a plu.

  • La documentation ! Si tous les frameworks pouvaient être aussi bien documenté (tacle ZF), se serait merveilleux. La doc en elle même suffit, elle est plein d’exemples et on se retrouve rarement à devoir chercher des tutos ailleurs
  • L’aide et les exemples : une petite recherche dans google qui vous emmènera probablement vers Stackoverflow et vous trouverez votre réponse dans la minute qui suit. Au départ les questions portent plus sur Python que sur Django :)
  • Les applications (comprendre « plugins ») : il existe déjà des applications pour un nombre incalculable de besoin. Authentification social, gestion de tache cyclique, éditeur wysiwyg, « boostrapiser » vos formulaires, gérer les assets, bref Github et djangopackages.com sont vos amis. Vous avez besoin d’une apps ? « pip install son-nom ».
  • L’ORM : pour le moment, je n’ai pas eu l’occasion d’utiliser quelque chose de mieux tout simplement. Les models se définissent très simplement, il n’y a pas d’accesseurs à entretenir, pas d’annonation (généralement mal géré par les IDE), tout est simple et limpide. Le requêtage est formidable. 
  • Le moteur de template : loin de Fluid ou Smarty qui nécessitent d’apprendre un pseudo langage … ce que je trouve lourdingue. Ici c’est tout simple, il y a 3 ou 4 trucs de base à savoir en gros : afficher une variable, faire une boucle et affiche un block. 
  • L’interface admin : certains frameworks commencent à le faire mais c’est semble t’il Django qui est au top la dessus. Une interface admin est toute prête et vous n’avez soin qu’à spécifier les modèles que vous souhaitez gérer. Il s’occupe du reste (CRUD) avec de l’ajax quand les modèles sont liés, des tris et filtres sur les listes d’enregistrements, organisation pour onglet, etc.
Une seule chose m’a quelque peu troublé au départ. Bien souvent les frameworks imposent une architecture souvent liée au MVC, comme par exemple un découpage par « application » sous ZF, par package sous FLOW3; chacun d’eux embarque un dossier pour les contrôleurs / modèles / vues. 
Django est beaucoup plus souple : il y a également un découpage « application » mais libre à chacun de faire ce qu’il veut de celle-ci, c’est un dossier vide. Pas d’obligation d’avoir une structure MVC dedans. L’application peut, par exemple servir à morceler votre site avec une application pour le frontend et une pour le backend. Ou bien, une application pour toutes les vues et une pour les modèles. 
Rien de dramatique mais c’est un légèrement perturbant lorsqu’on vient de framework très encadrants. Il n’y a pas de bonne façon de faire, à chacun de gérer.  

Un mot sur Python.

Voilà de nombreuses années que je fais du PHP et jusqu’à maintenant lorsque je lisais un article qui portait un regard critique sur PHP, … je dois avouer que j’avais du mal. En gros j’aurais dis : PHP se traine un lourd passé mais il permet de bien faire son boulot comme n’importe quel langage.
Aujourd’hui je dois bien avouer que lorsque je vois Django, il me semble indéniable que la qualité de ce framework est en bonne partie liée à Python. Ce que je veux dire c’est que même si Django a bien été conçu / pensé, reproduire ce framework dans un autre langage n’aura pas du tout eu le même résultat.
J’ai le sentiment que l’on se retrouve à avoir et à faire moins de couche, moins d’abstraction et à utiliser moins de pattern. Bref c’est mon sentiment et je ne me prétends pas expert.
En tout cas il va me falloir avaler encore quelques milliers de ligne de python avant de pouvoir être réellement efficace. Python regorge d’astuces et de fonctionnalités. Il y a des bouts de code de 2 lignes qui calment n’importe quel débutant pendant 1h :)

Conclusion

Django m’a totalement convaincu mais il faut bien avouer que pour l’heure il est encore assez peu utiliser en France. La monté en compétence sur ce framework est rapide et « fun ». J’ai franchement pris du plaisir à le faire … ce qui à moins été le cas avec FLOW3 ou Zend Framework.
Je reviendrai à FLOW3 parce qu’il y a plein de choses intéressantes dedans mais aussi parce que ce framework est de plus en plus lié à TYPO3 (Extbase, TYPO3 v6).

Et maintenant pourquoi pas Play! Framework ?

Utilisation de Zend Java Bridge – Part 1

Par défaut
Malgré que ce ne soit pas ma tasse de thé, aujourd’hui je vais m’essayer à la rédaction d’un billet un peu technique … je suis plutôt du genre codeur bourru (et barbu) qui a du mal à formaliser ses idées. N’hésitez donc pas à intervenir si vous voyez des erreurs.
Préambule

Je vais vous parler de JavaBridge, un composant où plutôt une fonctionnalité du Zend Server qui, pour faire simple, permet d’utiliser du code Java directement en PHP. A l’aide d’un exemple ces quelques billets vous monteront comment utiliser et structurer votre code afin de le rendre évolutif et mutualisable.

JavaBridge
Comme je le disais juste au dessus, JavaBridge, c’est le moyen d’utiliser des objets Java en PHP. Il existe deux « JavaBridge », le premier prenant la forme d’un module PHP indépendant et l’autre fournit avec Zend Server. Je ne me suis pas penché sur le sujet depuis longtemps mais je crois me souvenir que le premier choix comportait quelques limites, notamment au niveau des performances : une JVM de lancée par processus; Zend Server de son coté ne lance qu’une seule JVM.
Il n’y a pas meilleur exemple que le code :
$date = new Java('java.util.Date');
echo $date->getTime()

Aujourd’hui bon nombre de sociétés orientent leur architecture vers de la SOA pour des raisons de couts et d’évolutivités. Dans ce schéma on imagine donc parfaitement un serveur d’application Java (par exemple JBoss) portant le métier pour ensuite mettre à disposition un ensemble de services. En face, la partie cliente, des applications PHP diverses et variées utilisant des Frameworks (Symfony, Zend Framework) tout comme des CMS (Typo3, Drupal).

Les choses sont en place, un serveur Jboss SOA d’un coté et un Zend Server de l’autre utilisant JavaBridge. L’objectif est donc de consommer des services métiers Java en PHP. Petit exemple extrait de la page de Zend JavaBridge :
// Configuration pour EJB JBoss. Les autres serveurs d'applications Java peuvent nécessiter une configuration différente.
// Notez que le CLASSPATH doit contenir ces classes.
$envt = array(
"java.naming.factory.initial" => "org.jnp.interfaces.NamingContextFactory",
"java.naming.factory.url.pkgs" => "org.jboss.naming:org.jnp.interfaces",
"java.naming.provider.url" => " jnp://yourflowers.com:1099"
);
$ctx = new Java("javax.naming.InitialContext", $envt);

// Recherche de l'objet
$obj = $ctx->lookup("YourflowersBean");

// Ici, nous trouvons un objet - pas de gestion d'erreur dans cet exemple.
$rmi = new Java("javax.rmi.PortableRemoteObject");
$home = $rmi->narrow($obj, new Java("com.yourflowers.StoreHome"));

// $hw contient notre objet bean
$store = $home->create();

// ajoutez une commande au bean
$store->place_order($_GET['client_id'], $_GET['item_id']);
print "Order placed. Current shopping cart: ";

// récupération des données du caddie depuis le bean
$cart = $store->get_cart($_GET['client_id']);
foreach($cart as $item)

// Libére l'objet
$store->remove();

Comme vous pouvez le voir la mise en oeuvre est quand même relativement simple. Maintenant complexifions un peu la chose.

L’environnement de développement
Imaginons que nous ayons à développer une gestion de compte propre au métier d’une société au sein d’un CMS, Typo3 par exemple. Le CMS s’occupe uniquement de l’authentification front-office et nous laissons donc au serveur d’applications Java le soin de porter la gestion de compte qui comportera spécificités propres au métier de la société. Au passage, notre société s’appellera « Paypal ».
Un compte aurait comme caractéristiques le nom, le prénom, la date de naissance et le numéro de compte bancaire de la personne. Il y aurait aussi un autre type de compte, un compte dit « vérifié » où l’on aurait un peu plus d’informations : adresse postal et nom de naissance).
Bien, dans Typo3 nous aurons donc une extension que nous appellerons « gestcompte ». Dans cette extension nous aurons plusieurs plugins, l’un pour afficher les informations du compte (p1) et l’autre pour les éditer (pi2).
Assez rapidement nous allons nous rendre compte qu’une bonne partie du code risque d’être écrit plusieurs fois, notamment tout ce qui est connection au serveur JBoss. Il est aussi fort probable que nous ayons à récupérer l’adresse d’un compte ou tout autres informations depuis d’autres plugins.
Dans ce billet je m’appuie sur un IHM supporté par Typo3 mais la logique est la même que se soit pour une application « from scratch » ou conçue à l’aide d’un Framework. L’exemple est même relativement bidon :)
 
Nous allons donc essayer de développer une « librairie » mutualisable qui s’appuiera sur quelques design patterns. Nous l’appellerons « business-lib« .

Typo3 – Récupérer des infos sur une page

Par défaut

Il est parfois nécessaire de récupérer le titre et diverses autres informations sur une page (titre, sous titre, id page parent, etc), notamment pour générer un lien.

// $uid étant l'id de la page
$pageInfos = $GLOBALS['TSFE']->sys_page->getPage($uid);

// Pour les pages traduites
$pageInfos = $GLOBALS['TSFE']->sys_page->getPageOverlay($uid, $GLOBALS['TSFE']->sys_language_uid);