CMS basé sur Java avec service / API RESTful pour accéder au contenu

Question

Pour ceux qui pourraient voter pour fermer cette question en raison de "pas constructif - Dans l'état actuel des choses, cette question ne convient pas à notre format de Q&R." - Ce serait bien si vous suggériez où dois-je poster cette question ( https://softwareengineering.stackexchange.com/ ? ou tout forum dédié au CMS?)

Des questions similaires ont déjà été posées:

Ils ont tous quelques années, je me demande donc s'il y a de nouvelles recommandations/discussions à ce sujet.

Quelques antécédents: Nous sommes une boutique Java, nous créons/maintenons des sites Web pour nos clients, notre pile technologique est Java, Spring, SQL, JSP, HTML5, JQuery, Tomcat, JBoss, Maven, etc. ... jusqu'à présent en termes de "contenu", nous l'avons mis dans un fichier de propriétés lu par le JSP pour des copies (par exemple, la description du produit X) ou un service principal qui fournit un contenu dynamique (par exemple. quelle est la valeur actuelle du produit X).

Maintenant, nous repensons notre approche de la gestion du contenu, car nous gérons de plus en plus de propriétés pour le client avec le même contenu (par exemple, un site Web, un site Web mobile, une application mobile, etc.), nous voulons donc certainement éviter d'avoir plusieurs copies du même contenu diffusé.

Quelques choses que je recherche particulièrement:

Basé sur Java (parce que nous sommes Java shop: 1) plus d'expertise dans la gestion des choses basées sur Java et 2) évitons d'introduire une autre technologie dans la pile)
Extensibilité/personnalisation. Besoin de pouvoir personnaliser le CMS (c'est pourquoi nous voulons rester dans notre Java) afin qu'il puisse être étendu pour se connecter à d'autres services Web pour consommer du contenu, etc.
Concentrez-vous sur le contenu - nous avons besoin d'une séparation claire entre le contenu et le rendu de l'interface utilisateur, pour revenir à ce que nous recherchons où nous devrons fournir le contenu propriétés distinctes.
Service/API RESTful pour accéder au contenu - comme ci-dessus. Nous avons besoin que le contenu soit accessible directement en tant que JSON/JSON-P /. Flux XML.
Besoin d'avoir une interface utilisateur décente avec laquelle travailler et plus intuitif, mieux c'est pour les utilisateurs professionnels, car certains de nos clients qui pourraient être déplacés vers la plate-forme voudront probablement gérer leur propre contenu
Support multilingue
Open source/low cost

Jusqu'à présent, plusieurs options que j'ai sont:

Adobe CQ - Semble être la solution la plus idéale, mais malheureusement son coût est prohibitif

CMS Hippo - Semble correspondre à ce que nous recherchons, je ne sais pas dans quelle mesure il est documenté, les didacticiels/procédures semblent assez clairsemés, leur part de marché semble être plus importante en Europe qu'en Amérique du Nord.

Liferay - Plus ciblé en tant que "portail" par opposition au CMS fournissant du contenu

Alfresco - Plus axé sur les "documents"

dotCMS - Comme Hippo CMS, il semble que celui-ci puisse répondre à nos besoins.

CMS Magnolia - Regarde également dans la même allée que dotCMS et Hippo. D'après les commentaires que j'ai vus, ils semblent être davantage axés sur un seul site Web et non sur une séparation nette entre le contenu et l'interface utilisateur.

Personnellement, je n'ai pas beaucoup d'expérience directe avec CMS auparavant.

Vos réflexions/commentaires sur chacune des options ci-dessus, ou si vous avez d'autres solutions à l'esprit non mentionnées ici, seraient grandement appréciés! L'un de mes défis est que nous devons prendre une décision vraiment saine, car quelle que soit la voie que nous décidons de suivre, nous serions probablement coincés avec elle, la décision n'est pas quelque chose qui peut être facilement abandonnée et recommencer.

Koen Peters · Accepted Answer

Personnellement, j'ai une certaine expérience avec Hippo et beaucoup avec dotCMS. Je connais un peu Alfresco, Liferay et Magnolia mais je n'ai jamais travaillé avec eux auparavant. Je n'ai aucune expérience avec Adobe CQ, car je n'ai jamais pris le temps d'enquêter. Cela est dû au fait que les coûts élevés sont un pas pour beaucoup de nos clients. Alfresco est en effet une meilleure solution si vous recherchez un système de gestion de documents en ligne, ce que je ne pense pas. Vous avez raison sur le fait que Hippo, Magnolia et dotCMS sont quelque peu similaires, ce qui n'est pas si étrange car ils essaient de résoudre le même problème: être une classe Enterprise Java basé sur le système de gestion de contenu Web. Ils se concentrent fortement sur la gestion du contenu qui peut être utilisé dans des pages qui sont également gérables avec le CMS.

Pour être honnête: j'ai un penchant pour dotCMS parce que j'ai beaucoup travaillé avec les systèmes et j'en sais beaucoup. J'ai pensé expliquer pourquoi cela fonctionne pour nous afin que vous puissiez en tenir compte. Je travaille dans une boutique Java qui fait beaucoup de développement de middleware pour ses clients en utilisant JBoss et toute la pile EE. Nous connectons les anciens (Cobol) et les nouveaux systèmes ensemble et mettons une nouvelle interface Web brillante en plus de ce middleware qui cible à la fois les administrateurs et les consommateurs. Pour pouvoir créer ces interfaces, nous avons besoin d'un CMS qui fait bien quelques choses:

Basé sur Java (parce que nous sommes une Java cela nous permet de faire travailler les mêmes personnes sur le CMS et le middleware)
Évolutivité horizontale à des dizaines de serveurs sans trop de tracas. Dans le cas classique lors de la mise à l'échelle sur plusieurs serveurs, la base de données et le dossier des ressources sont partagés entre les nœuds. Cela pourrait être un problème lorsque vous avez de nombreux nœuds, mais en pratique, ce n'est pas un gros problème car la majeure partie de la charge atteindra l'index et non la base de données ou le disque. Dans les versions 2.5 et supérieures, dotCMS propose un mode "ne rien partager" dans lequel chaque nœud possède sa propre base de données et son propre dossier d'actifs, mais cela vous oblige à utiliser un serveur de création supplémentaire (lire: sous licence) qui envoie le contenu à chacun des nœuds. Je n'ai pas joué avec cette configuration moi-même, mais cela semble prometteur, surtout parce que chaque nœud peut être une boîte simple et bon marché qui n'utilise que postgresql/mysql et Tomcat et parce qu'il n'y a plus de point de défaillance unique. Dans le cas classique, si le dossier des ressources partagées ou la base de données mourrait, tous les nœuds seraient également en panne, sauf lorsque vous regroupez la base de données et le disque, ce qui est coûteux à faire. Avec cette configuration "ne rien partager", ce n'est plus le cas. Comme je l'ai dit: je n'ai aucune expérience avec cela, mais il semble que cela puisse fonctionner.
Interface d'administration utilisable à la fois par les utilisateurs avancés et les non-techniciens (clients). Tout le monde n'est pas "bon avec les ordinateurs", mais ils ont aussi besoin de pouvoir gérer le contenu (très souvent ces personnes travaillent dans le département marketing de nos clients). dotCMS offre des moyens de créer des interfaces d'administration qui ne montrent que quelques-unes des fonctionnalités offertes par dotCMS. Cela les empêche d'avoir à comprendre l'ensemble du système, ce qui accélère la formation et l'acceptation.
Contenu structuré. C'est biggie. Nous voulons être en mesure de définir de nombreux types de contenu, tous avec un ensemble fixe de champs, tout comme une table de base de données. Le tout sans avoir à reconstruire ou redémarrer le système. Les personnes qui définiraient le contenu sur la base de cette structure (le nom utilisé par dotCMS pour ces types) ne peuvent pas entrer de données non valides car le système protège contre cela. Cela rend la création de sites Web beaucoup plus pérenne et pratique. Surtout pour les développeurs.
Concentrez-vous d'abord sur le contenu. Les premiers mois où nous avons utilisé dotCMS, nous n'avons utilisé que dotCMS pour gérer le contenu lui-même et l'exposer via les API JSON. Nous n'avons pas utilisé de fonctionnalités CMS comme la définition de modèles et la création de pages. Cela fonctionne bien et ressemble à ce que vous recherchez. dotCMS dispose d'un service Web JSON/XML qui renvoie du contenu basé sur des requêtes. Nous l'utilisons beaucoup dans presque tous nos projets, voir ici pour plus d'informations: http://dotcms.com/docs/latest/ContentAPI . L'utilisation de dotCMS lui-même pour l'ensemble du front-end est également une possibilité. Surtout avec les contrôleurs Spring qu'il prend en charge et le nouveau concepteur de modèle agnostique du framework CSS, c'est une belle façon de construire des systèmes qui nécessitent plus que du contenu.
Multilingue. dotCMS propose plusieurs façons de procéder. Vous pouvez créer du contenu dans toutes les langues dont vous avez besoin, même du contenu non textuel tel que des images. En raison de l'approche "le contenu d'abord", beaucoup de choses sont du contenu dans dotCMS et peuvent être traitées comme telles, y compris la création d'une version pour chaque langue dont vous avez besoin.
Open source. dotCMS propose une version communautaire que nous utilisons la plupart du temps. Seulement pour les fonctionnalités pro comme l'équilibrage de charge, l'utilisation d'Oracle pour la base de données, etc., une version payante est nécessaire. Et même alors, les coûts sont gérables. Voir http://dotcms.com/products/editions/ pour plus de détails à ce sujet.
Mécanisme de mise en cache interne. En raison de la charge élevée, certains des sites que nous avons créés nécessitent une mise en cache. DotCMS utilise Google Guava pour leur mise en cache qui fonctionne plutôt bien.
Extensibilité, également un biggie. Nous devions être en mesure d'étendre les fonctionnalités de dotCMS pour des raisons évidentes. DotCMS n'offrait autrefois qu'une façon à l'ancienne de faire des plugins qui est un peu moche et est basé sur un script ant qui écrase les classes dotCMS avec les vôtres. Cela fonctionne bien, mais je me sens toujours sale après avoir écrit un tel plugin. Cependant, depuis la version 2, ils offrent un framework de plugins basé sur OSGi qui est assez doux et beaucoup plus convivial pour les développeurs. Il est sorti de la bêta dans la version 2.5. Nous prévoyons de porter tous nos plugins vers le nouveau framework.
Hôte multiple. Nous devons pouvoir héberger plusieurs sites dans le même CMS. DotCMS fournit cela nativement. C'est aussi une belle façon de partager des choses communes entre plusieurs hôtes que nous utilisons beaucoup.

Bien sûr, il y a aussi des inconvénients. Voici quelques-uns:

Les CMS Web comme dotCMS stockent son contenu dans une base de données et les actifs sous forme de fichiers sur le disque. Cela rend la gestion des versions et la synchronisation entre les différents serveurs une douleur dans le cul. À partir de la version 2.5, dotCMS propose des outils de synchronisation qui vous permettent de pousser le contenu d'un environnement (par exemple UAT) vers un autre (par exemple PROD), ce qui est utile. Mais ne pas pouvoir extraire une seule version du contenu de quelque chose comme GIT ou SVN est très ennuyeux. D'autant plus que nous, en tant que développeurs Java, nous sommes habitués à des choses comme les tests automatisés dans un environnement d'intégration continue. Bien sûr, vous pouvez stocker la base de données en tant qu'instruction SQL et le répertoire des ressources, mais c'est lent et pas si " Nice ". Mais là encore, tous les systèmes qui stockent l'état dans une base de données ont ce défaut.
DotCMS prend un certain temps à apprendre. Ce n'est pas un petit CMS comme Wordpress que vous comprendrez en un après-midi. Il a de nombreuses fonctionnalités et est très puissant, mais vous aurez probablement besoin d'un jour ou deux pour comprendre la manière dotCMS puis encore quelques jours pour comprendre toutes les API. Je vous encourage à lire d'abord quelques documents et à les bricoler avant de construire un vrai site de production: de nombreuses façons mènent à Rome, mais certaines consistent en sable mouvant. :)
DotCMS a RAM faim. Pour garder les choses rapides, il a tout mis en cache, donc si vous avez beaucoup de contenu, il rongera le RAM que vous avez disponible). Vous pouvez modifier cela, mais il est plus facile de lui donner suffisamment RAM nous avons trouvé.
Toutes les configurations du client d'édition WebDAV + ne sont pas compatibles avec dotCMS. Par exemple, sur un Mac, j'ai constaté que vous utilisiez au mieux Cyberduck comme client WebDAV et Aptana comme éditeur de texte. D'autres configurations font des choses bizarres que dotCMS n'aime pas beaucoup. Vous devez jouer un peu pour savoir quelle est la meilleure configuration pour vous. J'ai trouvé que si vous déposez un bug sur leur github ils le corrigent dans la prochaine version. Ils m'ont dit que WebDAV est difficile à comprendre car ce n'est pas une norme fixe que je comprends, mais cela peut quand même être pénible.

Si vous voulez apprendre dotCMS, lisez leur -pas si mal- documentation: http://dotcms.com/docs/latest/TableOfContents et jetez également un œil à leur site de démonstration ( http : //dotcms.com/products/demo/ ). Dans le site de démonstration, vous trouverez des exemples de tous les concepts offerts par dotCMS. Oh et découvrez également nos propres plugins dotCMS gratuits. En particulier, le minifieur JavaScript et CSS est très pratique: http://geekyplugins.com/ .

Espérons que cela aide un peu. Faites-moi savoir si vous voulez en savoir plus.

Von Lion · Answer

Clause de non-responsabilité: je travaille pour Hippo, je vais donc essayer de répondre uniquement par des faits et non par une opinion: -)

Hippo est entièrement Java, le frontal est indépendant du langage, mais orienté vers JSP ou Freemarker, vous pouvez éventuellement utiliser une interface REST et utiliser n'importe quoi.
De nombreux plugins sont créés et collectés sur la Hippo forge .
La conception centrée sur le contenu a été un élément essentiel du développement d'Hippo, ne devrait pas poser de problème.
Oui, par défaut, tous les appels JCR sont disponibles. En dehors de cela, vous pouvez définir votre propre interface REST pour répondre à vos besoins, exemple dans la démo , documentée ici .
J'ose dire oui, d'après mon expérience, la plupart des utilisateurs non techniques trouvent l'interface facile à comprendre.
Le multilingue est facile, fait partie de la configuration multicanal par défaut .
L'édition communautaire (qui est complète, pas d'appât et de changement) est open source, il y a fonctionnalité d'entreprise derrière une licence propriétaire . La licence ouvre également des avenues d'assistance, en plus de Google Group et Stack Overflow.

Maintenant, sur votre commentaire concernant la documentation incomplète, permettez-moi de donner mon avis: vous avez raison, la documentation est une lutte continue. La plupart des choses sont documentées, mais difficiles à trouver. Nous travaillons à l'amélioration des aperçus, des introductions et des tutoriels, mais nous n'avons évidemment pas encore terminé. Si vous ne trouvez rien, la communauté est généralement en mesure de vous aider et de vous orienter dans la bonne direction.