java - 基于 Java 的 CMS，带有 RESTful 服务/API 来访问内容

Question

对于那些可能因“不具建设性 - 目前看来，这个问题不适合我们的问答形式”而可能投票结束这个问题的人。- 如果您建议我应该在哪里发布这个问题（https://softwareengineering.stackexchange.com/？或任何以 CMS 为重点的论坛？）

之前也有人问过类似的问题：

• https://stackoverflow.com/questions/918722/java-or-php-for-homegrown-cms
• https://stackoverflow.com/questions/4005811/is-there-a-good-cms-for-java
• https://stackoverflow.com/questions/8298790/java-web-cms-recommendations
• https://stackoverflow.com/questions/4837502/recommendations-for-a-lightweight-java-web-cms
• https://stackoverflow.com/questions/1939238/can-you-recommend-an-easy-to-use-easy-to-develop-cms

他们都有几年的历史，所以我想知道是否有新的建议/讨论。

一些背景知识：我们是一家 Java 商店，我们为客户创建/维护网站，我们的技术堆栈是 Java、Spring、SQL、JSP、HTML5、JQuery、Tomcat、JBoss、Maven 等……通常的东西。到目前为止，就“内容”而言，我们要么将其放入 JSP 读取的某些属性文件中以获取副本（例如产品 X 的描述），要么将其放入提供动态内容的后端服务（例如产品 X 的当前值是多少） ）。

现在我们正在重新考虑管理内容的方法，因为我们正在为具有相同内容的客户管理越来越多的属性（例如网站、移动网站、移动应用程序等），因此我们绝对希望避免拥有多个副本相同的内容四处传播。

我特别要找的几件事：

1. 基于 Java（因为我们是 Java 商店：1）在处理基于 Java 的东西方面有更多的专业知识，2）避免将其他技术引入堆栈）

2. 可扩展性/定制。需要能够自定义 CMS（这就是我们想要坚持我们的 Java 专业知识的原因），以便可以将其扩展为与其他 Web 服务连接以使用内容等。

3. 专注于内容——我们需要明确区分内容与 UI 渲染，回到我们正在寻找的内容，我们需要将内容交付到单独的属性中。

4. 访问内容的 RESTful 服务/API - 同上。我们需要内容可以作为 JSON / JSON-P / 直接访问。XML 提要。

5. 需要有一个像样的 UI 来使用，并且对业务用户来说越直观越好，因为我们的一些可能被转移到平台的客户可能希望管理他们自己的内容

6. 多语言支持

7. 开源/低成本

到目前为止，我有几个选择是：

Adobe CQ - 看起来是最理想的解决方案，但不幸的是它的成本太高了

Hippo CMS - 看起来符合我们的要求，我不确定它的文档记录如何，教程/操作指南似乎很稀少，它们在欧洲的市场份额似乎比在北美更大。

Liferay - 与提供内容的 CMS 相比，更专注于“门户”

Alfresco - 更专注于“文件”

dotCMS - 与 Hippo CMS 一样，似乎这个可能适合我们的需求。

Magnolia CMS - 看起来与 dotCMS 和 Hippo 一样。从我看到的评论来看，他们似乎更专注于单个网站，而不是内容与 UI 之间的清晰分离。

我个人之前没有太多使用 CMS 的直接经验。

您对上述每个选项的想法/评论，或者如果您有其他未在此处提及的解决方案，我们将不胜感激！我面临的一个挑战是我们需要做出一个非常合理的决定，因为无论我们决定走哪条路，我们都可能会坚持下去，决定不是可以轻易放弃并重新开始的事情。

Answer 1

就我个人而言，我对 Hippo 有一些经验，对 dotCMS 也有很多经验。我对 Alfresco、Liferay 和 Magnolia 了解一些，但我之前没有与他们合作过。我对 Adob​​e CQ 没有任何经验，因为我从来没有花时间调查。这是因为高成本对我们的许多客户来说是不可行的。如果您正在寻找在线文档管理系统，Alfresco 确实是一个更好的解决方案，我认为您不是。您说得对，Hippo、Magnolia 和 dotCMS 有些相似，这并不奇怪，因为它们试图解决相同的问题：作为基于 Java 的企业级 Web 内容管理系统。他们非常注重管理可用于页面的内容，这些页面也可通过 CMS 进行管理。

老实说：我对 dotCMS 有偏见，因为我使用过很多系统并且对它了解很多。我想我会解释为什么它对我们有用，这样你就可以考虑到这一点。我在一家 Java 商店工作，该商店使用 JBoss 和整个 EE 堆栈为其客户开发大量中间件。我们将旧系统（Cobol）和新系统连接在一起，并在针对管理员和消费者的中间件之上放置了一个闪亮的新 Web 界面。为了能够创建这些界面，我们需要一个能够做好几件事的 CMS：

1. 基于 Java（因为我们是一家 Java 商店，这使我们能够让相同的人在 CMS 和中间件上工作）
2. 水平可扩展至数十台服务器，无需太多麻烦。在经典案例中，当扩展到多台服务器时，数据库和资产文件夹在节点之间共享。当您有许多节点时，这可能是一个问题，但实际上这不是一个大问题，因为大部分负载将命中索引，而不是数据库或磁盘。在 2.5 及更高版本中，dotCMS 提供“无共享”模式，其中每个节点都有自己的数据库和资产文件夹，但这确实需要您使用额外的（阅读：许可）创作服务器，将内容推送到每个节点。我自己没有玩过这个设置，但听起来很有希望，特别是因为每个节点都可以是一个简单而便宜的盒子，只使用 postgresql / mysql 和 tomcat 并且因为不再有单点故障。在经典情况下，如果共享资产文件夹或数据库将死亡，所有节点也会关闭，除非您将数据库和磁盘集群在一起，这很昂贵。有了这种“无共享”设置，情况就不再如此了。正如我所说：我没有这方面的经验，但听起来它可能会奏效。
3. 高级用户和非技术人员（客户）都可以使用管理界面。不是每个人都“擅长计算机”，但他们也需要能够管理内容（这些人通常在我们客户的营销部门工作）。dotCMS 提供了创建管理界面的方法，这些界面只显示了 dotCMS 提供的一些功能。这可以防止他们必须了解整个系统，从而加快培训和接受。
4. 结构化内容。这是个大问题。我们希望能够使用一组固定的字段定义多种类型的内容，就像数据库表一样。所有这些都无需重建或重新启动系统。将基于此结构（dotCMS 用于这些类型的名称）定义内容的人不能输入无效数据，因为系统会对此进行保护。这使得构建网站更加面向未来和方便。特别是对于开发人员。
5. 首先关注内容。我们使用 dotCMS 的最初几个月，我们实际上只使用 dotCMS 来管理内容本身并通过 JSON API 公开内容。我们没有使用定义模板和创建页面等 CMS 功能。这工作正常，听起来像你正在寻找的东西。dotCMS 有一个基于查询返回内容的 JSON/XML Web 服务。我们在几乎所有项目中都大量使用它，请参阅此处了解更多信息：http ://dotcms.com/docs/latest/ContentAPI 。将 dotCMS 本身用于整个前端也是一种可能。尤其是它支持的 Spring 控制器和与 CSS 框架无关的新模板设计器，这是构建不仅需要一些内容的系统的好方法。
6. 多种语言。dotCMS 提供了几种方法来做到这一点。您可以创建所需的所有语言的内容，甚至包括图像等非文本内容。由于“内容优先”的方法，很多东西都是 dotCMS 中的内容，可以这样对待，包括为您需要的每种语言创建一个版本。
7. 开源。dotCMS 提供了我们大部分时间使用的社区版本。仅对于负载平衡、使用 oracle 数据库等专业功能，付费版本是必要的。即便如此，成本也是可控的。有关此内容的更多详细信息，请参阅http://dotcms.com/products/editions/。
8. 内部缓存机制。由于高负载，我们构建的一些站点需要缓存。DotCMS 使用 Google Guava 进行缓存，效果很好。
9. 可扩展性，也是一个大问题。出于显而易见的原因，我们需要能够扩展 dotCMS 的功能。DotCMS 过去只提供一种老式的插件方式，这种方式有点难看，并且基于一个用你自己的覆盖 dotCMS 类的 ant 脚本。它工作得很好，但是写了这样一个插件后我总是觉得很脏。然而，从第 2 版开始，他们提供了一个基于 OSGi 的插件框架，该框架非常好用并且对开发人员更加友好。它在 2.5 版本中退出测试版。我们计划将我们所有的插件移植到新框架中。
10. 多主机。我们需要能够在同一个 CMS 中托管多个站点。DotCMS 本机提供此功能。这也是在我们经常使用的多个主机之间共享通用内容的好方法。

当然也有不利的一面。这里有几个：

1. 像 dotCMS 这样的 Web CMS 将其内容存储在数据库中，并将资产作为文件存储在磁盘上。这使得不同服务器之间的版本控制和同步变得很麻烦。从 2.5 版本开始，dotCMS 提供了同步工具，使您能够将内容从一个环境（例如 UAT）推送到另一个环境（例如 PROD），这很有帮助。但是无法从 GIT 或 SVN 之类的内容中签出单个版本的内容非常烦人。尤其是因为我们作为 Java 开发人员已经习惯了在持续集成环境中进行自动化测试之类的事情。当然，您可以将数据库存储为 SQL 语句和资产目录，但这很慢而且不是那么“好”。但话又说回来，所有将状态存储在数据库中的系统都有这个缺陷。
2. DotCMS 需要一些时间来学习。这不是一个像 Wordpress 这样的小型 CMS，您会在一个下午了解。它有很多特性并且非常强大，但是您很可能需要一天左右的时间来理解 dotCMS 方式，然后再过几天来理解所有的 API。我确实鼓励您在构建真正的生产站点之前先阅读一些文档并对其进行修改：许多方式都通向罗马，但其中一些方式是流沙。:)
3. DotCMS 需要内存。为了保持速度，它缓存了所有内容，所以如果你有很多内容，它会吃掉你可用的 RAM。您可以对此进行调整，但只为它提供我们找到的足够 RAM 会更容易。
4. 并非所有 WebDAV + 编辑客户端的配置都与 dotCMS 兼容。例如，在 Mac 上，我发现您最好将 Cyber​​duck 用作 WebDAV 客户端，将 Aptana 用作文本编辑器。其他设置会做一些 dotCMS 不太喜欢的怪事。你必须玩一点才能找出最适合你的设置。我确实发现，如果您在他们的github上提交错误，他们会在下一个版本中修复它。他们告诉我，WebDAV 很难做到正确，因为它不是我理解的固定标准，但它仍然会让人头疼。

如果您想学习 dotCMS，请阅读他们的 - 还不错 - 文档：http://dotcms.com/docs/latest/TableOfContents并查看他们的演示站点（http://dotcms.com/products/demo/）。在演示站点中，您将找到 dotCMS 提供的所有概念的示例。哦，看看我们自己的免费 dotCMS 插件。尤其是 JavaScript 和 CSS 缩小器非常方便：http ://geekyplugins.com/ 。

希望这有所帮助。如果您想了解更多信息，请告诉我。

Answer 2

免责声明：我为 Hippo 工作，所以我会尽量只用事实而不是意见来回答:-)

1. Hippo 完全基于 Java，前端与语言无关，但面向 JSP 或 Freemarker，您可以选择使用 REST 接口并使用任何东西。

2. 许多插件都是在Hippo forge中创建和收集的。

3. 以内容为中心的设计一直是 Hippo 开发的主要内容，应该没有问题。

4. 是的，默认情况下所有 JCR 调用都可用。除此之外，您还可以定义自己的 REST 接口以满足您的需求，例如演示中的示例，在此处记录。

5. 我敢说是的，根据我的经验，大多数非技术用户都觉得这个界面很容易理解。

6. 多语言很简单，是默认多通道设置的一部分。

7. 社区版（完整，没有诱饵和转换）是开源的，专有许可证背后有一些企业功能。除了Google Group和 Stack Overflow之外，该许可证还开辟了支持途径。

现在，关于您对文档不完整的评论，让我提出我的意见：您是对的，文档是一场持续的斗争。大多数东西都有记录，但很难找到。我们正在努力改进概述、介绍和教程，但显然我们还没有完成。如果您找不到任何东西，通常社区能够提供帮助并为您指明正确的方向。