Mon livret de messe - Générateur de PDF

Bonjour,

Ce petit billet pour vous parler d'un site que j'ai développé pour ma femme et dont l'adresse est http://monlivretdemesse.fr. Ce projet que je développe depuis plusieurs années, a été mis à jours récément. Je profite de cette mise à jours pour vous parler de ce projet fonctionnellement mais aussi techniquement.

Monlivretdemesse.FR est un site permettant aux utilisateurs allant se marier de générer leur livret de messe au format PDF afin de l'imprimer directement chez eux. Les pages du livret ainsi générées sont alors ordonnées de telle manière qu'il suffit de faire une impression recto/verso puis de plier les feuilles pour avoir son livret. Je me suis chargé du développement de ce site, pendant que ma femme se charge du contenu (donc le contenu des textes, des images, mais aussi et surtout le thème de chaque produit, leur format).

La nouvelle version sortie le 11 mars 2014 permet également la création d'autres types de produits afin de générer des

• livrets de messe de baptêmes
• faire-parts de mariage, de baptêmes
• menus pour la soirée
• des marques places
• et bien d'autres...

Le site a été écrit à l'aide du framework Symfony2 et utilise la bibliothèque TCPDF afin de générer les fichiers PDF. Les données sont stockées dans une base de données MongoDB. Parmi les données on peut compter les données produits, utilisateurs, mais aussi le cache des PDF générés enregistrés en tant que fichier dans GridFS (et ceci afin qu'un livret qui n'a pas été modifié ne soit pas re-généré).

Symfony2

Symfony 2 est un framework PHP permettant le développement de sites Internet. Il est livré par défaut avec un ORM: Doctrine qui permet de faire correspondre à une structure de base de données des classes PHP qui seront automatiquement hydratées.

Le développement PHP s'en retrouve presque agréable (je préfère les langages compilés en règle générale). Le framework est de la même trempe que le Framework Python Django.

Ce dernier m'a d'ailleurs tenté (bien qu'interpreté aussi), mais une lecture rapide de la documentation m'a donné l'impression d'être un peu moins pratique à utiliser que Symfony2. Peut-être car je ne fais pas de Python.

Pour mon prochain projet j'étudierai l'utilisation de symfony2 vs ruby on rails vs django vs node.js. Mais je ne suis pas sûr qu'au final l'utilisation d'une des technos précédentes m'apporte beaucoup plus par rapport à ce que sait déjà faire un framework comme symfony2. L'avantage d'un tel framework réside aussi dans le nombre de bundle et de librairie utilisables à l'extérieur.

Par rapport à la distribution de base de symfony2 j'ai remplacé la version Doctrine ORM par Doctrine ODM. Ce qui me permet de me connecter à une base de données MongoDB.

MongoDB

Mon projet d'abord basé sur une base MySQL a été basculé sur une base de données NoSQL nommée MongoDB.

La raison n'est pas technique (je n'ai pas besoin de replication, de sharding, ...., pas assez de visiteurs). J'avais juste envie de tester cette base de données sur mon projet. De plus l'aspect orienté document est agréable au développement.

En effet, au lieu de stocker les informations dans différentes tables et de tenter d'y accéder à l'aide de jointure ou de requête multiple, dans on MongoDB on stocke un document dans un format binaire du JSON (le BSON).

Un panier stocké en base pourra avoir la forme :

{
  "_id": ObjectId("......................"),
  "expiration_updated_at": ISODate("2014-03-17T21:00:34.0Z"),
  "lines": [
    {
      "product": {
        "product": "marque-place-baroque-dore",
        "product_name": "Marque-place baroque doré",
        "variant": "dore-gris",
        "variant_name": "Doré\/Gris",
        "amount": 7.9
      },
      "custom": ObjectId("....................")
    }
  ],
  "lines_count": NumberInt(1)
}

On retrouve dans un seul document les informations liées au panier et les informations concernant chaque ligne. La dénormalisation n'étant pas un problème, on rappelera alors ici le nom du produit, et le nombre de lignes que l'on pourrait retrouver autrement mais qui permettra un affichage plus rapide de cette manière.

Par exemple, sur la page d'acceuil où on affiche le nombre de produit dans le panier, il nous suffira de requêter lines_count sans toucher à l'attribute lines. Ensuite lors de l'affichage du panier, on récupérera les lignes et les informations du panier en une seule requête et sans jointure.

Ainsi pour des entités avec forte relation, qu'on ne récupère jamais les unes sans les autres, une seule requête permet de récupérer toutes les informations. Par exemple, dans une base relationnelle, on aura l'habitude de stocker l'entête du panier dans une table, et les lignes dans une autre table. Avec Mongo, si je veux récupérer le panier en une requête, je récupère aussi les lignes. Cela implique par contre de ne pouvoir requêter facilement sur les lignes du panier indépendamment de leur entête.

Le seul problème que j'ai actuellement avec l'ODM Doctrine est que la mise à jour du panier se fait en plusieurs requêtes alors qu'il serait préférable de le faire en une seule pour des questions d'atomicité. Ce point fait d'ailleurs l'objet du ticket 437 du Github du projet.

Les différents modules du site

Dans cette section je vais vous parler rapidement des différents bundle que j'ai créé pour le site.

Le CMS

Afin de faciliter l'édition des pages de contenu (Mention légales, Documentation, FAQ) sans toucher au code. J'ai écrit un mini CMS. Le but est de stocker dans la base de données les différentes pages du projet, ainsi que les images associées aux pages.

Pour cela j'ai un bundle nommé CMS qui utilise la notion d'édition inline de CKEditor. J'ai écris mon propre Explorer de media qui permet de récupérer et ajouter dans cette même base des fichiers à attacher aux différentes pages.

L'adresse de la page est alors décomposée pour récupérer la clé de la page. Une page dont l'adresse sera /page/prout aura comme clé en base /prout. Pour un utilisateur non administrateur (ou anonyme), si la page est trouvée, elle est affichée telle quelle et si elle n'est pas trouvée, une page 404 est affichée.

En mode administrateur si la page existe, elle est ouverte en mode édition inline pour CKEditor. Si la page n'existe pas, elle est ouverte en mode création et en mode inline avec CKEditor. Il est ainsi super facile pour un administrateur de créer de nouvelles pages.

La partie media permet d'ajouter dans un GridFS dedié les images, et fichiers attachés.

Le module est du coup assez simple, deux documents

• Page
• Media

Le document Page ressemble à ceci:

/**
  * Page
  *
  * @MongoDB\Document(collection="cms_page")
  */
class Page {
    /**
      * @var string
      *
      * @MongoDB\Id(strategy="CUSTOM", options={"class"="\Shadoware\CMSBundle\Generator\PageSlugGenerator"})
      */
    private $slug;

    /**
      * @var string
      *
      * @MongoDB\String
      */
    private $name;

    /**
      * @var string
      *
      * @MongoDB\String
      */
    private $title;

    /**
      * @var string
      *
      * @MongoDB\String
      */
    private $content;

    /**
      * @var string $lang
      *
      * @MongoDB\String
      */
    private $lang;
}

Le controlleur est assez simple :

/**
  * @Route("/page/{slug}", requirements={"slug" = ".+"})
  * @Template()
  */
public function indexAction($slug) {
    $dm = $this->get('doctrine_mongodb')->getManager();

    $page = $dm->getRepository("CMSBundle:Page")->find($slug);
    if ($page == null) {
        if ($this->get('security.context')->isGranted('ROLE_ADMIN')) {
            $page = new Page();
            $page->setTitle("Titre de la page");
            $page->setSlug($slug);
            $page->setName("Nom");
            $page->setContent("Contenue de la page");
        } else {
            throw $this->createNotFoundException("Page not found");
        }
    }

    $request = $this->getRequest();
    if ($request->getMethod() == "POST" && $page != null) {
        $page->setName($request->get('name'));
        $page->setTitle($request->get('title'));
        $page->setContent($request->get('content'));

        $dm->persist($page);
        $dm->flush();
    }

    return array('page' => $page);
}

Et enfin la vue Twig contient les références à CKEditor et l'activation du contenu modifiable inliné pour les projets. Pour l'instant le module est fortement lié à l'application existante. J'ai dans l'espoir d'avoir assez de temps un jour pour externaliser ce module afin de pouvoir le partager à plus de monde.

Si vous avez envie d'avoir plus d'information sur ce bundle n'hesitez pas à me contacter et je vous réponderez avec joie.

Les produits

La partie produits et beaucoup plus liée à l'activité du site. Les produits contiennent pour chaque colori, un modèle dans lequel sont définis la position des différentes informations qui seront par la suite saisies par l'utilisateur. Ma femme peut ainsi, après avoir préparé son modèle le personnaliser sur le site.

Un document de type produit personnalisé permet ensuite de spécialiser le produit en y ajoutant les informations saisies par l'utilisateur. C'est ce produit final qui est ensuite acheté par l'utilisateur.

Les paiements

La partie paiement contient la gestion du panier, de la facturation et le lien avec le site Paypal. En effet on utilise l'API de paypal pour effectuer les paiements car nous n'avions pas l'envie de gérer pour ce site un système de paiement onéreux et complexe. Paypal prélève un pourcentage de la transaction, et permet le paiement par carte bancaire des utilisateurs anonymes, ce qui nous convient.

Au niveau du panier, certaines informations sont enregistrées, comme le nombre de lignes dans le panier, ainsi que le nom du produit et le nom du coloris choisis afin de faciliter le requêtage et l'affichage.

La gestion des utilisateurs

La gestion des utilisateurs passent par FOS/UserBundle. Quelques personnalisations ont été ajoutées à ce module afin de correspondre au thème du site et aussi pour ajouter quelques informations.

Le site

Ajoute les CSS et javascript personnalisés du site. Le theme a été acheté à une époque sur un site proposant des templates, mais à depuis été customizé et adapté pour notre utilisation.

L'admin

L'interface d'administration permet à femme et à moi d'accéder aux différents produit, d'en créer de nouveau, de les modifiers. L'interface se base sur un thème bootstrape et reste assez simple. Seul l'utilisateur avec le role d'administrateur peut accéder à cette page.

Dans l'avenir.

Le découpage actuel ne me plaît pas forcément. En effet, je charge des bundles propres à l'admin sur le site alors que ces derniers pourraient être chargés uniquement dans le cadre de l'admin et inversement. Je pense qu'appliquer une architecture comme celle décrite ici: http://jolicode.com/blog/multiple-applications-with-symfony2, pourrait être une bonne idée pour mieux découper l'application.

Dans le même style, la partie CMS actuelle est liée au site, et j'aimerais la découpler du site pour pouvoir l'utiliser assez facilement dans d'autres projets.

Mes contributions

Lors du développement de mon projet, j'ai eu besoin de certaines fonctionnalités que je n'ai pas trouvées dans les bundles existants ou qui ne me convenaient pas. Je vous présente ici différents projets que j'ai développé pour pallier à ces manques, sachant que pour l'instant ceux-ci ne sont pas parfaits et voir même, la documentation peut laisser à désirer (quand aux tests unitaires ils sont dans le néant).

Si vous souhaiter aider ou contribuer, n'hésitez pas.

CollectionBundle

Lien: CollectionBundle

Dans symfony, il est possible d'ajouter dans un formulaire un type collection pour permettre à un utilisateur de saisir une collection de sous-éléments (jointure de type OneToMany):

$builder->add('emails', 'collection', array(
    // chaque item du tableau sera un champ « email »
    'type'   => 'email',
    // ces options sont passées à chaque type « email »
    'options'  => array(
        'required'  => false,
        'attr'      => array('class' => 'email-box')
    ),
));

Le problème c'est que dans les formulaires symfony2 il n'est pas possible de gérer des formulaires différents suivant le sous-type de l'objet (gestion de l'héritage dans l'ORM).

CollectionBundle propose deux nouveaux types :

• Un type permettant de gérer pour chaque classe fille, un formulaire différent.
• Un type permettant de gérer des collections de taille fixe : Exemple toujours 5 éléments, quel que soit le nombre d'éléments rééls en base.

Ce bundle est actuellement utilisé uniquement dans la partie admin du site.

DoctrineMigrationODMBundle

Lien: DoctrineMigrationODMBundle

Pour l'ORM Doctrine, il existe DoctrineMigrationBundle qui permet de faire des migrations de schéma, mais il n'existait pas d'équivalent pour l'ODM gérant MongoDB.

Même si MongoDB est schemaless, et que les données peuvent être migrées à l'execution, je ressens le besoin d'avoir la possiblité d'exécuter des scripts lors des changements de version, pour :

• ajouter de nouvelles données (nécessaires) dans des tables (car on requête sur ces données).
• renommage de collection, suite à gros refactoring.
• voir autre

FPDI et FPDF_TPL

Pour la génération des PDF, je génère une première version où chaque page est un élément différent, puis je me sers de FPDI pour associer les différentes pages sur une même page (avec la mention SPECIMEN ou pas).

Afin d'avoir accès à FPDI je me suis créé les dépôts suivants qui fonctionnent avec ceux de tecnick.com/tcpdf pour les utilisateurs de TCPDF.

Liens:

• http://hg.shadoware.org/Software/Symfony2Bundle/fpdi
• http://hg.shadoware.org/Software/Symfony2Bundle/fpdf_tpl

ImageResizerBundle

Lien : ImageResizerBundle

Dérivé de https://github.com/nresni/ImageResizerBundle, ce bundle ajoute

• des caches supplémentaires
• fournit une URL sur la valeur du cache directement (et de générer le cache lors de l'appel de la commande twig). Cette dernière permet de cacher un peu l'URL utilisée pour accéder à l'image d'origine. On ne peut accéder alors qu'à l'URL finale. Comme les ids des images sont des ObjectId, il n'est pas possible de retrouver par le nom l'URL de l'image d'origine.

Cette extension est utilisée par toute l'application pour l'affichage de toutes les miniatures.

PiwikBundle

Lien : PiwikBundle

Ce plugin a été créé afin de pouvoir ajouter la gestion de Piwik dans Symfony2. Les commandes PIWIK peuvent être passées au travers d'un service ou au travers de commandes TWIG. Ce plugin gère également la notion d'e-commerce de PIWIK.

Une fois le plugin installé (via composer), il faut l'activer à l'aide de la configuration suivante:

shadoware_piwik:
  base_url: http://monpiwik.monsite # URL de base du serveur PIWIK
  id_site: 1 # N° du site dans PIWIK
  hidePiwik: false # Indique s'il faut cacher le tracker par un controlleur interne.
  tokenId: abcedfghijkmn123456789 # Le token id de l'utilisateur (pour le cas où on cache piwik)
  heartbeat: ~ # Permet de définir quelques attributs activant la fonctionnalité de heatbeat de piwik.

Une fois la configuration faite, le plugin ajoutera juste avant chaque balise l'appel à piwik (en utilisant la méthode asynchrone). Si la page ne contient pas de balise ou si elle constitue une page de redirection, les informations seront déportées à l'affichage suivant.

Cette dernière fonctionnalité permet par exemple d'ajouter des éléménts au panier e-commerce piwik lors des pages de redirection, et de traiter son affichage dès que possible. Cela a par contre comme limitation de ne pas gérer les conflits.

L'utilisation depuis un controlleur se fait grâce à l'utilisation du service:

$this->container->get('shadoware_piwik.service')->addEcommerceItem($productId, $productName, $category, $amount);
$this->container->get('shadoware_piwik.service')->trackEcommerceCartUpdate($totalAmount);

L'utilisation depuis une page twig se fait à l'aide des commandes twig. Par exemple dans la page twig de base:

<title>{{ 'title' | trans }} - {% block title %}{{ 'menu.home' | trans }}{% endblock %}</title>
{{ setPiwikPageName(block('title')) }}

Conclusion

Bon voilà j'espère vous avoir fait découvrir le site ainsi que quelques nouveaux plugins intéressant.

A bientôt,