eZ Publish & Déploiement d'une plateforme multi-site
- Publié le 11 Juillet 2009
- 4 commentaire(s)
- Catégorie : Technologies Web
eZ Systems à publié un report ainsi que les slides de la eZ Conference 2009 (25 & 26 Juin à Paris). On y retrouve donc mes slides, laborieusement rédigés en anglais, mais qui m'ont finalement sauvés la mise sur quelques situations critiques...
Je profite de ce billet pour revenir sur quelques points précis, et en Français, ce qui devrait faciliter certaines explications, et m'éloigner un peu plus des eZ Awards... A ce propos, bravo à Damien pour son prix largement mérité, surtout pour l'excellent développement "Ze French Corner !"
Voir tous les slides du Community & Developer Track.
Le choix du mono ou du multi base
En complément des slides qui décrivent les avantages et les inconvénients de chacune des architectures, dans le meilleur des mondes, voici quelques critères (ou contraintes) supplémentaires à considérer dans un contexte professionnel.
- Les montées de versions sur du multi base : Il ne faut pas négliger le temps de travail et l'organisation que peut nécessiter la montée de version d'un gros volume de sites, surtout concernant la synchronisation nécessaire entre l'unique installation eZ, et la nécessité que toutes les bases soit "upgradées" avant la remise en production. Selon le volume il peut s'avérer indispensable de scripter les montées de versions avec toute l'organisation que cela implique (plan de migration, scripts à tester et rejouer, monitoring sur les incidents...)
- La collaboration entre les développeurs sur du mono base : Il est fréquent sur les logiques de multi publication que plusieurs développeurs ou agences interviennent sur le même projet. Certes les outils de versionning (type SVN) permettent de très bien gérer et partager les fichiers (extensions, settings et autres templates), mais cela se complique sur le partage des données (classes, workflow, rôles & policies...). Il est même fréquent que cette contrainte force certaines orientations vers du multi base, en générant beaucoup d'effets de bords. Il n'existe pas de solution miracle, à part de bon outils de collaborations, et un architecte central pour centraliser et modérer les choix et les manipulations des données
La recherche
Les slides ne sont pas très compréhensibles sur ce sujet, et encore moins mon explication orale pendant la conf (gros moment de solitude)... alors quelques explications en Français
- Situation 1 : Il est fréquent de partager des référentiels entre les différents sites publiés (médias, listes de catégories, fiches diverses, etc.)
- Situation 2 : Il est fréquent d'exploiter ces référentiels dans chacun des sites à l'aide des relations d'objets (les emplacement secondaires sont parfois inexploitables sur certains types d'affichages, devant évolués en fonction des dates, des arbres de contenus, ou autres paramètres très profonds ou aléatoires)
- Situation 3 : D'un façon générale il est fréquent de parcourir (avec des Fetch) des contenus externes à l'arbre de contenu principal
Problème : par défaut il n'est pas possible d'afficher des résultats de recherche qui se situent à l'extérieur de l'arborescence principal du site.
- Solution 1 : Faire de l'indexation frontale (avec Google sitesearch, ou avec Nutch pour rester dans la sphère eZ Find / SolR). Cette solution ne permet par contre pas de profiter pleinement des filtres et autres facettes qui font la force de eZ Find
- Solution 2 : En attendant que eZ Find permette la gestion des relations, pourquoi pas gérer soit même l'inventaire des objets additionnels à considérer lors d'une recherche (en gros tout ce qui n'est pas dans l'arbre de contenus principal), par exemple en peuplant une table SQL sur certains déclencheurs (workflow, ou encore pendant le processus de l'opérateur de template générant les liens).
Localisation :
Que boire avec ce billet ?
Domaine Belles Pierres - Chants des Âmes - Rouge 2004
| Région : | Languedoc |
| Appellation : | Coteaux du Languedoc - Saint Georges d'Orques |
| Domaine : | Domaine Belles Pierres |
| Couleur : | |
| Stock : | 0 |
| Notation : | |
| Prix : | 15 € |
| Commentaire(s) : | 0 Commentaire(s) |
Le terroir de Saint Georges D'orques produit depuis quelques années des grands vins rouges (et blanc), comme cette très belle cuvée, concentré en fruits rouge et aux tanins soyeux. Si vous êtes patient quelques années, et que vous carafez cette cuvée une bonne heure avant dégustation, vous ne le regrettrez pas.
Source photo : http://www.cavesnotredame.fr/
eZ Find
Petite remarque concernant eZ Find et les relations: ce n'est effectivement pas facilement réalisable pour le moment, par contre avec un peu de développement, 100% faisable pour du spécifique (rendre l'API accessible est le plus gros challenge de l'intégration, et ce n'est pas indispensable dans ce cas).
Mais à suivre.
Sinon, assez bon résumé de la situation. Un outil d'upgrade plus automatisé et un peu générique resterait une solution acceptable en attendant les évolutions du process de mise à jour.
ezWebsiteGeneratorExtension
J'ai parcouru tes slides, très intéressante cette extension, bravo belle réalisation.
A quand la version ez certified?
En fait je me demandais autre chose. Ez inclus déjà certaines fonctionnalités que tu duplique via la classe de contenu template_look. Pourquoi ne pas utiliser un template_look et common_ini par website?
Dans la version mono DB j'ai pas bien compris le pb des contenu hors arbre et le custom operator ezurl, tu pourrai détailler le trick (shared)/XX ??
Dernier point, Site en maintenance concrêtement tu fais quoi derrière? d'ailleurs je pense que pour le coup c'est un très bon candidat pour un object state non?
cheers
RE: ezWebsiteGeneratorExtension
@Pourquoi ne pas utiliser un template_look et common_ini par website?
Je ne trouve pas ce concept séduisant, puisqu'on peut le reproduire avec beaucoup plus de modularités et de libertés d'actions. Cependant, je ne l'ai pas assez exploité pour savoir si cela fonctionnerait ou pas.
@Dans la version mono DB j'ai pas bien compris le pb des contenu hors arbre :
Voir le détail dans le billet, c'est relativement détaillé
@custom operator ezurl, tu pourrai détailler le trick (shared)/XX ??
Il s'agit d'afficher un noeud en dehors de l'arbre du site courant. Ce contenu est "fetchable", mais pas atteignable dans le contexte du site. Il faut donc proposer un mécanisme pour afficher le noeud dans le contexte du site (par exemple un view_parameter sur le home page), et générer des liens contenant l'appel de cette URL, par exemple pour les listes résumés ou les résultats de recherche dont le lien pointe vers ce contenu.
@Site en maintenance
Modification dynamique des droits anonymes sur le noeud racine du site. Objects states n'est pas trop adapté à la situation.
Fond du post ?
Le point que tu soulèves semble être l'hétérogénéité des contenus et leur interfaçage probable avec un moteur de recherche.
Globalement, depuis l'avènement de solutions de type Nutch et Lucène, l'indexation est reportée et non pas effectuée de suite car trop gourmande (je suppose) en performances.
Avec la normalisation des webservices et l'agrégation quasi systématique des applications et de leur contenus, des solutions plus envisageables font leur apparition avec un coût certain bien évidemment :
http://www.google.com/enterprise/gsa/
En gros, le principe est simple, on a une machine de fou dédiée à l'indexation et au traitement des requêtes et de l'autre côté on insère un "client" dans chaque applications pour qu'il permette l'indexation. Malin.
Bref on est revenu au bus de données.
