Download the PHP package truffo/ez-content-decorator-bundle without Composer
On this page you can find all versions of the php package truffo/ez-content-decorator-bundle. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download truffo/ez-content-decorator-bundle
More information about truffo/ez-content-decorator-bundle
Files in truffo/ez-content-decorator-bundle
Package ez-content-decorator-bundle
Short Description A short description of what your package does
License MIT
Homepage https://github.com/truffo/ez-content-decorator-bundle
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package ez-content-decorator-bundle
ez-content-decorator
Introduction
Lorsqu'on travaile sur des templates, eZ Publish fournit généralement 2 objects :
- location : représentant la localisation dans l'arborescence
- content : représentant le contenu proprement dit
Ces 2 éléments suffisent dans la majorité des cas, mais très vite, le besoin d'étendre ces 2 objets se fait ressentir.
Un exemple classique consiste à récupérer dans le controleur la liste des enfants d'une location à travers une LocationQuery, on va le paginer et le passer à la vue.
La vue affichera un listing avec un chapo, le chapo sera constitué soit du champ chapo soit du champ du contenu principal coupant à un certains nombres de caractères.
Bref, un grand classique du Web.
Classiquement, on va répéter ses opérations des dizaines et dizaines de fois. Et, comme il y a plusieurs développeurs sur le projets, chacun va avoir des petites différences :
- entre ceux qui préfère exclure les types de contenus qui ne conviennent pas, et ceux qui préfère inclure uniquement ceux qui conviennet
- entre ceux qui préfère calculer le maximum de chose dans un controleur et ceux vont déléguer à des sous requetes
On a trouvé un manque d'harmonie et des copier / coller d'un type de contenu à l'autre, et à chaque changement c'est le bal des retours lients interminables, en gros, on a un terreau à dette technique.
L'idée : un décorator
Ce bundle fournit un mécanisme très simple pour apporter une solution concrète à cette problématique, il permet d'avoir très simplement et très rapidements des décorator qui encapsule nos types de contenus dans une structure plus souple.
L'idée est simple, il s'agit d'abord de regrouper sous une même classe les éléments qui constituent un contenu :
- la location
- le content
C'est la classe ContentDecorator. Bon, ok cela ne sert pas à grand chose.
Cette classe va nous servir de classe de base pour définir nos decorators pour les instance concrète.
Chaque classe permet de définir des méthodes qui sont propres à chaque type de contenu.
Enfin, on exploite la configuration sémantique pour faire le lien entre la classe et type de contenu.
On notera que l'on peux avoir un mapping différent par siteaccess grâce à la configuration sémantique. Ce qui peut être très pratique dans des plate-forme multisites.
Le service ContentDecoratorFactory permet d'instancier la bonne classe en fonction du type de contenu.
Chargement automatique
A ce stade, pour exploiter ce mécanisme, il faut :
- charger le décorateur à chaque appel dans le contrôleur
- charger le décorateur directement dans la vue via un opérateur Twig custom
Ce n'est pas terrible comme solution, surtout qu'eZ Publish fournit, un Event le PreContentView Listener qui nous permettre de charger automatiquement le decorateur et injecter les variables dans le template.
On a ainsi 2 variables qui sont automatiquement disponibles dans tout les templates qui ont une Location en paramètre :
-
- decorator
Elles sont identiques, ce sont juste des sucres syntaxiques.
Ainsi dans une vue full d'un article, on pourrait avoir le code suivant :
ou son équivalent
Chargement automatique dans les listes
On a trouver une solution pour charger automatiquement dans les vues contenant une location. Maintenant, pour les résultats de recherche, c'est presque aussi simple.
Une bonne pratique consiste à utiliser à systématiquement un pager (PagerFanta) pour récupérer les résultats d'une query via le SearchService. Ce composant à l'avantage de permettre d'injecter des adpaters.
Le LocationDecoratorSearchAdapter injecte automatiquement notre décorator à chaque instance des locations retournées.
Dans nos repositories, on peux avoir quelques choses qui ressemble à cela :
et dans notre controlleur
Ainsi dans notre vue, on a directement des décorateurs :
La réutilisabilité horizontale avec les traits
Les mécanismes présentés ci-dessus sont encore plus puissants si on utilise les égalements les traits de PHP. Reprenons notre exemple du chapo, on va pouvoir écrire quelques choses qui ressemble à ceci :
Une bonne convention sur le nommage des champs dans les différents type de contenu, avec ce bundle et les traits. On peux exploiter au maximum la réutilisabilité et la concision du code, CQFD.
