Introduction
Dans un précédent billet, je vous ai présenté l’initiative de grafikart: http://blog.developpez.com/ducodeetdulibre/p12482/outilsweb/comment-choisir-son-framework-php
Sur les prochains billets, nous allons détailler, analyser et comparer la manière de faire de chaque framework.

But de ce billet : Symfony 2
Dans ce billet, nous allons essayer de comprendre comment s’organise la création de page avec chaque framework:
Pour rappel, dans un site web, on à un template général, appelé « layout », qui contient notre bandeau/logo, nos menus de navigation ainsi qu’une partie dynamique: le contenu de notre site.
Nous allons voir ici, comment ont choisi le layout à utiliser (on peut en avoir plusieurs), puis comment on intègre la navigation, et comment on choisit quel template de vue utiliser pour l’affichage de notre contenu.

Voilà la page que nous allons étudier ici:

On peut voir 4 zones:

• Le bandeau
• La navigation des catégories
• La navigation des derniers posts
• Le contenu dynamique

Le layout
Pour afficher la page d’accueil, on appelle la classe controller PostController:
/src/Acme/BlogBundle/Controller/PublicController.php

Il n’y a pas d’indication sur le layout à charger ici, il est précisé plus tard dans la vue

La/les vues
Lorsque l’on regarde l’action appelée pour afficher cette page d’accueil:

Qui appelle la méthode listPosts()

On peut lire ici que l’on appelle la vue:
/src/Acme/BlogBundle/Resources/views/Public/index.html.twig

On peut lire en amont de cette vue que l’on étend la vue AcmeBlogBundle:Public:layout.html.twig
Voyons à quoi ce layout ressemble:
Pour information, il se situe ici:
/src/Acme/BlogBundle/Resources/views/Public/layout.html.twig

On retrouve ici un appel d’extension du layout base.html.twig
/app/Resources/views/base.html.twig

On voit également l’affichage du layout AcmeBlogBundle:Public:sidebar
/src/Acme/BlogBundle/Resources/views/Public/sidebar.html.twig

La syntaxe {{ render(controller(‘AcmeBlogBundle:Public:sidebar’)) }} dans le layout indique qu’il appelle la méthode sidebarAction du module public
/src/Acme/BlogBundle/Controller/PublicController.php

Retour au sommaire

Introduction
Dans un précédent billet, je vous ai présenté l’initiative de grafikart: http://blog.developpez.com/ducodeetdulibre/p12482/outilsweb/comment-choisir-son-framework-php
Sur les prochains billets, nous allons détailler, analyser et comparer la manière de faire de chaque framework.

Le listage des posts coté admin avec Laravel 4
Voici la page en question:
Une liste de posts, paginé avec des liens pour ajouter, modifier et supprimer ceux-ci.

L’adresse URL est index.php/admin
Le fichier controlleur concerné est application/classes/Controller/Admin.php

Dans la méthode action_index(), on a le code suivant:

On voit ici pour assigner des variables à la vue, via la méthode set() sur l’objet retourné par la méthode statique View::factory() de la vue.

note: ici la pagination et la liste des posts sont « fusionnés »: on assigne à la vue un objet de pagination contenant les posts.

Qui fait appel à la méthode findAll du model application/classes/Model/Post.php

note: on a pas la méthode de recupération dans la couche model post, mais dans le controller:

Et enfin la vue html de listage en elle même:
Fichier module/privatePosts/view/list.php

Où on a le code suivant:

On retrouve les variables $posts passé du controlleur plus haut

Retour au sommaire

Introduction
Dans un précédent billet, je vous ai présenté l’initiative de grafikart: http://blog.developpez.com/ducodeetdulibre/p12482/outilsweb/comment-choisir-son-framework-php
Sur les prochains billets, nous allons détailler, analyser et comparer la manière de faire de chaque framework.

Le listage des posts coté admin avec MkFramework
Voici la page en question:
Une liste de posts, paginé avec des liens pour ajouter, modifier et supprimer ceux-ci.

L’adresse URL est public/postadmin
Le fichier controlleur concerné est module/privatePosts/main.php

Dans la méthode _list(), on a le code suivant:

On voit ici pour assigner des variables à la vue, on instancie d’abord un objet view, puis on lui assigne des propriétés.

Qui fait appel à la méthode findAll du model model/model_posts.php

Et enfin la vue html de listage en elle même:
Fichier module/privatePosts/view/list.php

Où on a le code suivant:

On retrouve les variables this->tPost et this->oPagination passés du controlleur plus haut (via une assignation de propriété à l’objet vue)

Retour au sommaire

Introduction
Dans un précédent billet, je vous ai présenté l’initiative de grafikart: http://blog.developpez.com/ducodeetdulibre/p12482/outilsweb/comment-choisir-son-framework-php
Sur les prochains billets, nous allons détailler, analyser et comparer la manière de faire de chaque framework.

Le listage des posts coté admin avec Kohana
Voici la page en question:
Une liste de posts, paginé avec des liens pour ajouter, modifier et supprimer ceux-ci.

L’adresse URL est index.php/admin
Le fichier controlleur concerné est application/classes/Controller/Admin.php

Dans la méthode action_index(), on a le code suivant:

On voit ici pour assigner des variables à la vue, via la méthode set() sur l’objet retourné par la méthode statique View::factory() de la vue.

note: ici la pagination et la liste des posts sont « fusionnés »: on assigne à la vue un objet de pagination contenant les posts.

Qui fait appel à la méthode findAll du model application/classes/Model/Post.php

note: on a pas la méthode de recupération dans la couche model post, mais dans le controller:

Et enfin la vue html de listage en elle même:
Fichier module/privatePosts/view/list.php

Où on a le code suivant:

On retrouve les variables $posts passé du controlleur plus haut

Retour au sommaire

Introduction
Dans un précédent billet, je vous ai présenté l’initiative de grafikart: http://blog.developpez.com/ducodeetdulibre/p12482/outilsweb/comment-choisir-son-framework-php
Sur les prochains billets, nous allons détailler, analyser et comparer la manière de faire de chaque framework.

Le listage des posts coté admin avec Zend framework 2
Voici la page en question:
Une liste de posts, paginé avec des liens pour ajouter, modifier et supprimer ceux-ci.

L’adresse URL est public/admin/posts
Le fichier controlleur concerné est module/Blog/src/Blog/Application/Post/Controller/PostController.php

Dans la méthode indexAdminAction(), on a le code suivant:

On voit ici que pour assigner des variables à la vue, on retourne un tableau: chaque clé sera une variable disponible dans la vue: ici posts (qui contiendra le tableau des posts) et paginator (un objet pour gérer la pagination)

Qui fait appel à la méthode getActivePost du model /module/Blog/src/Blog/Business/Repository/PostRepository.php

Et enfin la vue html de listage en elle même:
Fichier module/Blog/view/blog/post/index-admin.phtml

Où on a le code suivant:

On retrouve les variables posts et paginator passé du controlleur plus haut (via un return)

Retour au sommaire

Introduction
Dans un précédent billet, je vous ai présenté l’initiative de grafikart: http://blog.developpez.com/ducodeetdulibre/p12482/outilsweb/comment-choisir-son-framework-php
Sur les prochains billets, nous allons détailler, analyser et comparer la manière de faire de chaque framework.

Le listage des posts coté admin avec Symfony 2
Voici la page en question:
Une liste de posts, paginé avec des liens pour ajouter, modifier et supprimer ceux-ci.

L’adresse URL est /admin/
Le fichier controlleur concerné est src/Acme/BlogBundle/Controller/AdminPostController.php

Dans la méthode indexAction(), on a le code suivant:

On voit ici que pour assigner des variables à la vue, on utilise la méthode render, et en deuxième argument on passe un tableau.

Qui fait appel à la méthode findAllQuery du model /src/Acme/BlogBundle/Entity/PostRepository.php

Et enfin la vue html de listage en elle même:
Fichier /src/Acme/BlogBundle/Resources/views/AdminPost/index.html.twig

Où on a le code suivant:

On retrouve la variable posts passé du controlleur plus haut.

Retour au sommaire

Introduction
Pour le jour 2, on profite des avantages du SVG:

• on peut selectionner un objet en cliquant dessus sur le dessin
• on peut deplacer un objet par drag and drop
• on peut exporter l’image généré

Sélection d’objet sur le dessin
Lorsque l’on dessine un objet, on met en temporaire l’id de celui-ci,
Dans le fichier public/js/data.js

Et dans le fichier public/js/canvas.js

Deplacement des objets en drag and drop
Ici la modification se fait en plusieurs endroits:
Dans public/js/canvas.js on active le drag and drop via l’event onMouseDown/onMouseUp

La méthode startDrag() dans la classe public/js/application.js

Et endDrag()

Ensuite, sur la div où l’on affiche le svg, on ajoute un attribut onMouseMove

Qui permet de gérer le moment où l’on déplace l’objet

Exportation de l’image
On ajoute ici un bouton pour exporter l’image

et la fonction concerné qui récupère le svg généré via la méthode innerHTML du dom

Le formulaire soumis

Enfin, coté php pour afficher le code svg envoyé dans le module default, action « export »

Le fichier layout layout/download.php

Projet Github
Le projet est toujours hebergé ici: https://github.com/imikado/mkdrawsvg

Introduction
Dans le précedent billet, je vous indiquais avoir entrepris la migration du projet MkDraw de canvas à SVG.

Etat d’avancement
La migration s’est plutot bien passé, la majorité du code à migrer étant centralisé dans les classes javascript Canvas.js et Application.js

Les gros changements canvas vers SVG
Si la migration a été rapide, je me retrouvais dans une situation peu propre, et surtout non satisfaisante:
En remplacant le code dessinant sur un objet canvas par le code SVG adéquat, je me retrouvais dans une situation, ou j’avais des div qui remplaçait mes canvas, je faisais comme pour l’application canvas, j’affichait ou cachait des calques en jouant sur l’attribut display de la div.
Mais cela ne donnait pas le resultat escompté: impossible d’interagir avec les objets sur l’espace de travail: en effet, chaque forme dessiné étant dans un div posé les uns aux dessus des autres il m’etait impossible d’user des avantages du format SVG.
J’ai donc repenser le mode de fonctionnement des calques pour qu’on arrive au final à générer un seul fichier SVG

Les avantages de cette version par rapport à MkDraw
Vous pouvez cliquer sur les objets sur l’espace de travail: chaque groupe contient un attribut onClick qui permet de passer l’objet en édition.
Vous pouvez donc cliquer sur un objet pour le sélectionner, puis cliquer à un autre endroit pour l’y déplacer.
Ensuite, lorsque vous souhaitez dessiner un nouvel objet, l’espace de travail passe en rouge, avec une opacité de 50%: en effet, lorsque vous dessiner une nouvelle figure, il me faut la créer en SVG, et je ne peux pas l’inclure dans le SVG global, car c’est une figure temporaire.
Par exemple quand vous créer un rectangle, vous cliquez une première fois pour debuter l’angle haut gauche, puis vous deplacer la souris pour definir les dimensions de celui-ci. Ce faisant, il faut à chaque déplacement de la souris modifier cet objet temporaire, et ce n’est qu’une fois le second clic effectué que la nouvelle figure sera ajoutée au calque sélectionnée:

Il y a un attribut onMousemove permettant de dessiner « Ã  la volée » le futur objet

Pour permettre ceci, j’ai toujours un div « canvas_tmp » dont l’attribut display passe à bloc (avec une transparence de 50%) seulement lorsqu’on clique sur un objet à ajouter, sinon ça cacherait mon svg et annulerait les interactions des objets

Projet Github
Le projet est toujours hebergé ici: https://github.com/imikado/mkdrawsvg

Introduction
Il y a quelques mois j’ai travaillé sur un projet d’application web permettant de dessiner des schémas en utilisant le canvas.
Un membre du forum « SylvainPV » (que je remercie au passage) m’avais demandé pourquoi je n’avais pas utilisé SVG à la place du canvas.
Le projet étant bien avancé (sans parler du fait que je connaissais plus canvas qu’SVG) je ne me voyais pas tout reprendre de zéro en changeant de technologie de dessin.

Mais suite à des retours sur l’application actuelle, j’ai remis les mains dans le code et analysé l’effort à faire pour modifier la méthode de dessin du canvas au SVG

Canvas VS SVG
Deux technologies qui ont leurs avantages et inconvénients, deux technologies différentes de dessin l’un dessine en bitmap (canvas) l’autre en vectoriel (SVG)
Les avantages dont je souhaite profiter en migrant cette application

• Permettre de selectionner un objet sur le calque en cliquant dessus
• Profiter du format vectoriel: on peut ainsi augmenter la taille du schéma sans perdre en qualité
• Permettre d’ajouter des fenêtre contextuel + des liens sur les objets

Un des défauts de la version Canvas, c’est que l’on dessine sur une image, mais il est ensuite difficile de sélectionner sur l’espace de travail un objet pour pouvoir le déplacer, redimensionner ou autre. Pour pallier à ce problème j’ai ajouté des petits icones de crayons en utilisant des « div » avec un lien javascript.

L’objet de la migration
Pour migrer en SVG, il faut supprimer toute trace de canvas: on garde les div utilisés mais on ne dessine plus sur le canvas.
Pour dessiner en SVG on créé dans le DOM de la page HTML du code SVG.

Quelques exemples de migration
On modifie ici principalement le fichier public/js/canvas.js
On passe de ceci:

A ceci (note je ne peut pas mettre les chevrons inférieur et suppérieur remplacé ici par « [ » et « ] »)

Projet Github
Le projet est disponible sous licence LGPLv3 ici https://github.com/imikado/mkdrawsvg