Oh la la !! Festival de nouveautés ! J'ai fait plein de trucs pendant mon silence (pas tant que ça mais quand même :)) et me revoila pour vous dire ce que j'ai compris. Je suis contente parce que comme j'ai appris de nouveaux sujets, j'ai de quoi parler ici.
J'ai l'impression que je n'ai fait que des posts sur les installations de projets sur mon poste local. Pourtant, lorsque je cherche, je ne trouve rien... Bon, je n'ai pas beaucoup cherché non plus :p Alors, pour moi, comme pour vous, voici ce que je fais, pour installer un projet.
Une aide de vue, c'est un moyen de rajouter un plugin dans vos vues (soit partout, soit dans une vue particulière) : un encart, un sous-menu, une liste des derniers commentaires etc...
Crédit : Morguefile.com
To check out a tab, we only need one field in a form. If the amount paid is less than the invoice, it is impossible to checkout the tab. If the amount paid is more than the invoice, we count the difference as a tip.
Crédit : Morguefile.com
Pour encaisser la note, il n'y a qu'un seul élément de saisie de formulaire (input text). Si le paiement (donc le montant saisi) est inférieur, la note n'est pas soldée, on refuse de clore la note. Si le paiement est supérieur, on considère que la différence est le pourboire.
Chacun des modules d'une application MVC avec Zend Framework 2 doit obligatoirement avoir une classe Module. Cette classe Module n'hérite d'aucune autre classe et sa documentation, quoique présente, est atypique. Voici donc la classe Module et ses méthodes.
Crédit : Morguefile.com
Service is running. Prepared food is served. Ordered drinks are served. As they are served, the application is counting the bill. Our clients are done. They want to close the tab... pay the bill.
Crédit : Morguefile.com
Le service se fait. Les boissons commandées, les plats préparés sont servis les uns après les autres. Doucement, le total des éléments servis s'additionne. Maintenant, les clients souhaitent quitter la table... Et payer la note.
Crédit : Morguefile.com
Now our staff can see in one look the list of drinks and food to be served, per table number. We have two different events. Let's listen to them.
Crédit : Morguefile.com
Le staff peut à présent voir en un coup d'oeil la liste des boissons et des plats à servir, par table. On a vu ensemble que les plats servis et les boissons servies ne déclenchaient pas tout à fait le même événement. Voyons à quoi s'en tenir désormais dans nos observers.
Crédit : Morguefile.com
Food is prepared, drinks are ordered... all they are waiting for is to be served. This is the waiters job. And we do have several waiters in the cofffeebar. So we need to assign the right todo list to the right waiter. We wouldn't assign a tab to a waiter who are not in charge of that table, right ?
Crédit : Morguefile.com
Les boissons sont commandées, les plats sont préparés, il reste à les servir. C'est la tâche des serveurs. Cette fois-ci, l'équipe est composée de plusieurs serveurs. Il faut donc préparer une liste par serveur, toutes leurs tables confondues.
Crédit : Morguefile.com
Now food is prepared and ready to serve... The 'foodPrepared' event has been triggered. But we know it well by now, nothing will ever happen if nobody is listening to this event. So now, let's add some listeners... ok, we (almost) know which listeners, but what about callbacks ?
Crédit : Morguefile.com
Les plats sont préparés et prêts à servir. L'événement 'foodPrepared' a été déclenché. Voyons ce qu'il déclenche dans nos différents observers.
Crédit : Morguefile.com
The chef knows what he has to do. The list of items to prepare are now displaying on screen. Once the chef has prepared an item, he needs to advise the staff that the item can now be served.
Crédit : Morguefile.com
Maintenant que le chef accède à la liste des plats à préparer, il faut que le chef puisse marquer les plats qui ont été préparés et qui sont désormais prêts à servir.
Crédit : Morguefile.com
In our previous chapters, food and drinks have been ordered. Though a drink can be served immediately, food has to be prepared before being served. It is the chef job to prepare food. Today, let's see how to display the chef todo list : what food he has to prepare.
Crédit : Morguefile.com
Dans les articles précédents, les boissons et les plats ont été commandés. Une boisson peut être servie immédiatement mais un plat doit être adressé à la cuisine pour être préparé. Le plat pourra être servi uniquement lorsqu'il sera prêt. Dans l'article d'aujourd'hui, nous allons gérer la todo list du chef et afficher la liste des plats commandés.
Crédit : Morguefile.com
When we place an order, two events are triggered. One event advising the drinks have been ordered and the second event advising the food has been ordered. Based on the initial workflow, the food and drinks do not follow the same process. Let's see how to differentiate each process.
Crédit : Morguefile.com
Lorsqu'on place une commande, deux événements sont déclenchés. Un premier événement qui signale que les boissons sont commandées et un second événement qui signale que les plats sont commandés. Selon le workflow défini initialement, les plats et les boissons ne suivent pas le même traitement. L'article d'aujourd'hui mets en place - du moins pour le début - les deux traitements différents.
Crédit : Morguefile.com
We have now created our place order form, with that nice repeat-my-fields feature in the previous chapter. In today's chapter, we will process the form, binding it to an object and, of course, triggering our events.
Crédit : Morguefile.com
Le formulaire pour passer la commande est créé et fonctionne convenablement. Dans l'article d'aujourd'hui, nous verrons comment on va associer le formulaire avec un objet et de cet objet, comment on va réussir à déclencher nos événements.
Crédit : Morguefile.com
To place an order, we will build a complex form with a fieldset : a drop down list and an input text. The numbers of fieldset is infinite and we can add as many fieldset as we need. Let's do some form dependencies and javascript in today's chapter.
Crédit : Morguefile.com
Pour passer commande, nous allons mettre en place un formulaire avec un ensemble de champs : liste déroulante et champ de saisie libre pour chaque élément de menu. On pourra ajouter autant d'éléments de menu que l'on voudra dans notre formulaire. Un peu de dépendances et de javascript dans le tutoriel d'aujourd'hui.
Crédit : Morguefile.com
In today chapters, we will see how we can manage the logic around the PlaceOrder command. Keep in mind we have only one form to order drinks and food. But we have two different workflows so we have to know, when the order is placed, which item is a drink and which one is a food and send the item in the correct workflow.
Crédit : Morguefile.com
Dans l'article d'aujourd'hui, nous allons voir comment on articule la logique métier autour de l'opération de passer commande. Il faut garder à l'esprit qu'il n'y a qu'un seul écran pour passer commande, à la fois pour les plats comme pour les boissons. Or, nous avons deux workflows distincts pour les boissons et pour les plats. Il faut donc, des éléments commandés, distinguer les boissons des plats et les envoyer dans les bons éléments.
Crédit : Morguefile.com
Our application is taking shape more and more. We have already built our main components and services. We have dumped unceremoniously the items from the cache. Now let's see if we can do better.
Crédit : Morguefile.com
Notre application se structure de mieux en mieux. Nous avons nos principaux éléments et services désormais en place. Nous avons effectivement triché en affichant les éléments du cache de manière un peu... violente. Mettons maintenant les choses en forme pour un rendu plus sérieux.
Le routing, c'est le fait d'associer une requête (URL) à des fichiers qui se trouvent sur le serveur... C'est la correspondance qui se fait entre l'URL qu'on saisit dans la barre d'adresse du navigateur et le (ou les) fichiers qui vont contenir le code nécessaire à la construction des informations qui vont être retournées vers le navigateur (on parle de "page web"). On sait tous, de nos jours, qu'UNE page web n'est plus l'affaire d'une page (et une seule)... Si le routing, ça ne vous dit rien, c'est parce que la plupart du temps, ça s'est fait tout seul... Plus maintenant.
Crédit : Morguefile.com
We have created previously a service responsible of managing the story of one tab only. Now, we will create a service bound to manage all the opened tabs. This new service will store the list of opened tabs and will list all the tabs status for the usage of the staff.
Crédit : Morguefile.com
Nous avons créé précédemment un service qui est chargé de s'occuper de l'historique d'une note indivuellement. Maintenant, nous allons nous occuper de gérer la liste des notes ouvertes. Nous allons utiliser un nouveau service pour cela. Celui-ci va stocker la liste des notes ouvertes et pourra afficher le statut de chaque notes à l'usage du staff du café.
Après avoir vu comment on mettait en place un inputFilter (ensemble d'élément Input), on voit maintenant comment appliquer des validateurs sur chaque élément Input de notre inputFilter.
Crédit : Morguefile.com
We have triggered our very first event in our previous chapter : 'openTab'. Now, we will set a service to catch the events triggered and process the business rules to it.
Crédit : Morguefile.com
Nous avons déclenché notre premier événement dans l'article précédent : 'openTab'. Maintenant, il va falloir mettre en place un service qui va intercepter les événements et qui va appliquer les règles métiers.
Après avoir vu comment on mettait en place un inputFilter (ensemble d'élément Input), on voit maintenant comment appliquer des filtres sur chaque élément Input de notre inputFilter.
Les fonctionnalités de formulaire de ZF2 permet de monter à la volée (ou programmatiquement) des éléments pour filtrer et valider vos éléments de formulaire. Pour un élément de formulaire (Zend\Form\Element), il y a un élément Input (Zend\InputFilter\Input), à l'élément global Zend\Form\Form, il y a la correspondance Zend\InputFilter\InputFilter.
Crédit : Morguefile.com
Once we have created a form - which open a tab, we will assign an object to it and use that object while processing the form. We will see how this object will trigger our very first event, the starting point of our application.
Crédit : Morguefile.com
Maintenant que nous avons notre formulaire - qui ouvre une note - nous allons lui attacher un objet. Avec cet objet, nous allons pouvoir traiter le formulaire. Nous verrons alors comment avec cet objet, nous allons pouvoir déclencher notre tout premier événement, le point de départ de toute notre application.
Crédit : Morguefile.com
In this chapter, we will build the form. Its particularity is to include a drop down component with customized datas. Let's take advantage of this application to learn how to create a customized Select component with a dependency.
Crédit : Morguefile.com
Dans cet article, nous allons construire un formulaire dont la particularité est de comporter une liste de sélection avec des données personnalisées. Profitons de cette application pour voir comment créer un élément Select de formulaire avec une dépendance.
Crédit : Morguefile.com
There are tutorials which are starting explaining the thing and then showing the first views after several chapters. Since i didn't know how to organize this one, i started to put the logic first then the views afterward. But i find it too frustrating to have to wait for the end of the tutorial to see what's happening. And truth is, in the real world, i need to see what is happening anyway.
Crédit : Morguefile.com
Il y a des tutoriaux qui commence par tout expliquer avant de présenter une première vue après plusieurs chapitres. C'est ce que j'ai commencé à faire avec notre application. Mais je trouve que c'est trop frustrant d'attendre avant de découvrir ce que l'application donne. Et puis, pour ma part, j'ai besoin de voir ce que je développe. Il me faut un retour écran, de toutes façons.
Crédit : Morguefile.com
To start with our coffeebar application, let's start by installing our framework first. We will work with Zend Framework 2. This framework allows us to build nice web applications using the MVC architecture and when running, the application will launch automatically a bunch of managers : Service manager, Event manager, Form elements manager which will be very useful in our case.
Crédit : Morguefile.com
Pour commencer notre petite application de gestion des commandes d’un petit café, installons d’abord la base de l’application. Nous travaillerons avec Zend Framework 2. Ce framework permet de monter des applications web en se basant sur l'architecture Modèle-Vue-Controleur, et l'application charge par défaut des gestionnaires de services, d'événements et de formulaires qui nous seront bien utiles.
Une petite bafouille pour me rappeler comment on injecte les dépendances dans le constructeur du contrôleur
A quick post on how to inject dependencies into our controller's constructor.
Pour me souvenir comment on gère les dépendances lorsqu'on crée des éléments personnalisés dans les formulaires.
Personal reminder about how to code dependencies in custom select element in forms.
Définir les routes en utilisant la configuration uniquement
Crédit : Stefano Paolini
En architecture trois tiers, le troisième tiers est la couche d'accès aux données. Afin d'accéder à votre couche d'accès aux données, Zend Framework a créé la classe TableGateway (et consoeurs).
Pour gérer la couche persistence des données, Zend Framework 2 propose Zend Db TableGateway. Zend Db TableGateway est un bon composant du framework mais demande un peu d'investissement. En remplacement au TableGateway, vous pouvez ajouter la librairie Doctrine à votre application.
Comment configurer un objet Zend avigation en utilisant la configuration seulement J'espère que cette liste va vous aider à utilsier Zend avigation
J'ai songé un moment mettre les méthodes du solveur dans mon objet grille (après tout, la résolution se fait à partir des éléments de la grille), mais finalement, je vais distinguer un objet Grille et un objet Solveur. L'objet Grille aurait pour responsabilité d'afficher et de manipuler la grille, et l'objet Solveur aurait pour responsabilité de gérer la résolution de la grille. Voyons donc cet objet Solveur.
Notre solveur avance petit à petit. Nous avons déjà mis en place nos objets principaux : les chiffres, la grille et la case. Chacun sait - jusqu'à nouvel ordre - ce qu'il a à faire. Avant de nous attaquer véritablement au moteur de résolution, occupons nous de la paire contrôleur / vue pour nous amuser un peu avec le "rendu".
Terminons le développement de l'objet Grille. Rappelons que nous savons accéder à toutes les cases de la grille, ou bien à une seule de ses cases. Nous connaissons la taille de la grille et nous pouvons mettre un chiffre dans une case ou bien écarter un chiffre possible d'une case.
Dans le développement d'un modèle en programmation orientée objet, vous serez nécessairement amené à créer plusieurs objets mais la plupart du temps, vous allez construire un principe de poupées russes avec des objets appelés par d'autres objets appelés par d'autres objets... Jusqu'à ce qu'on parvienne à l'objet qui sera au dessus de tout, l'objet "de niveau supérieur". L'objet de niveau supérieur est l'objet qui sera véritablement "utilisé". Dans le cas d'une application MVC, l'objet de niveau supérieur sera utilisé par le contrôleur. Ou, dans le cas d'une application Zend Framework 2, l'objet qui sera chargé dans le Service Manager.
Dernier petit détour avant les festivités : le test unitaire pour le contrôleur. On en n'a pas vraiment besoin pour cette application, mais j'en ai profité pour voir comment on pouvait faire ça.
On a eu la brillante idée de rendre la taille de la grille de sudoku variable. Il va donc falloir prévoir un moyen pour sélectionner la taille de la grille. Le mécanisme est le suivant : - dans la vue, on crée une interface qui va permettre à l'utilisateur de choisir la taille de sa grille (soit une liste déroulante, soit des liens) - en fonction du choix opéré sur l'interface, le paramètre va être envoyé dans le contrôleur. - le contrôleur récupère le paramètre pour l'exploiter (typiquement, pour envoyer cette information au modèle)
Comme je ne suis pas un génie en développement, je vais commencer par préparer ma vue. Deux avantages dans le cadre d'un développement empirique comme j'ai l'habitude de faire : - on détermine d'ores et déjà la structure de la grille que le contrôleur va envoyer dans la vue. - une fois que la vue est prête, on pourra vérifier "de visu" chaque étape du développement.
Crédit : zend framework
There's something I can't deny... As much the solution provided is flexible, as much there will be at least one person who'll wish to bend it to his will... Here, I'm attempting to customize the path to my Module.
Comment configurer les writers d'un objet Zend og ogger en utilisant la configuration seulement.
Alors que j'étais en train de développer une application avec Zend Framework 1, j'ai fini par tout reprendre à zéro en changeant de framework. Je ne suis pas allée chercher ma nouvelle librairie très loin puisque mon choix s'est porté sur Zend Framework 2. J'étais toutefois assez anxieuse de cette modification parce que j'ai eu un peu de mal pendant la période d'apprentissage du premier Zend Framework. J'ai pensé que je n'avais peut être pas la patience de tout réapprendre... Et c'est à ce moment là que je découvre le module dans Zend Framework 2.
Dans la première partie de ce dyptique, nous avons vu que la configuration d'une application montée avec Zend Framework 2 était répartie sur plusieurs fichiers chargés successivement. Nous avons également vu l'ordre de chargement de ces fichiers : la configuration de l'application en premier lieu, la configuration de chacun des modules, avec, rappelons le, la priorité au premier module trouvé, et enfin le chargement en toute fin des modules supplémentaires. Chaque module contient des informations propres et un élément de Zend se charge de fusionner tous ces différents fichiers de configuration. Voyons maintenant ce que contiennent ces fichiers de configuration.
Une application MVC développée avec Zend Framework 2 se structure grâce à des modules. La volonté de l'équipe de développement de Zend Framework est de créer des unités indépendantes les unes des autres. Cela permet de développer des modules qui peuvent facilement être branché et débranché d'une application. Afin de faciliter cet effet plugin, il faut savoir que chaque module embarque avec lui son propre fichier de configuration (contrairement à Zend Framework 1 qui concentrait la configuration dans un seul fichier de configuration). Mais que faut il savoir devant la démultiplication des fichiers de config ?
Crédit : zend framework
Finalement, au rythme où je vais, deux options s'offrent à moi : soit je finis mes applications en Zend Framework 1 et j'enchaine direct avec leur refactoring en Zend Framework 2, soit je passe directement à Zend Framework 2 en reprenant tout depuis le début avec la nouvelle librairie.