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

Java-based CMS with RESTful service / API to access content

提问by TS-

For those who might vote to close this question due to "not constructive - As it currently stands, this question is not a good fit for our Q&A format." - Would be great if you would suggest whereshould I post this question (https://softwareengineering.stackexchange.com/? or any CMS-focused forum?)

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

Similar questions have been asked before:

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

• 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

• 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

All of them are a few years old, so I am wondering if there are new recommendations / discussions around this.

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

Some background: We are a Java shop, we create / maintain websites for our clients, our tech stack are Java, Spring, SQL, JSP, HTML5, JQuery, Tomcat, JBoss, Maven, etc ... the usual stuff. So far in terms of "content" we either put it in some properties file read in by the JSP for copies (eg. description of product X) or back-end service that provide dynamic content (eg. what's the current value of product X).

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

Now we are rethinking our approach to managing content because we are managing more and more properties for the client with the same content (eg. a website, mobile website, mobile app, etc), so we definitely want to avoid having multiple copies of the same content spread around.

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

A few things I am particularly looking for:

我特别在寻找的一些东西：

1. Java-based (because we are Java shop: 1) more expertise in handling Java-based stuff and 2) avoid introducing another tech to the stack)

2. Extensibility / customization. Need to be able to customize the CMS (which is why we want to stick within our Java expertise) so that it can be extended to connect with other web services to consume content, etc.

3. Focus on content- we need clear separation between content vs UI-render, going back to what we are looking for where we will need to deliver the content into separate properties.

4. RESTful service / API to access the content - same as above. We need the content to be accessible directly as a JSON / JSON-P /. XML feed.

5. Need to have a decent UI to work with and the more intuitive the better for business user because some of our client that might be moved to the platform will likely want to be manage their own content

6. Multilingual support

7. Open source / low cost

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

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

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

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

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

6. 多语言支持

7. 开源/低成本

So far, several options that I have are:

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

Adobe CQ- Looks to be the most ideal solution, but unfortunately it's cost prohibitive

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

Hippo CMS- Looks to fit what we are looking for, I am unsure of how well it's documented, tutorial / how-tos seems to be quite sparse, their market share seems to be bigger in Europe than in North America.

Hippo CMS- 看起来符合我们正在寻找的东西，我不确定它的记录情况如何，教程/操作指南似乎非常稀少，它们在欧洲的市场份额似乎比在北美更大。

Liferay- More focused as "portal" as opposed to CMS providing content

Liferay- 更侧重于“门户”，而不是 CMS 提供内容

Alfresco- More focused on "documents"

Alfresco- 更专注于“文档”

dotCMS- Like Hippo CMS, seems like this one might fit our needs.

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

Magnolia CMS- Looks around the same alley as dotCMS and Hippo as well. From the comments I've seen seems like they are more focused on a single website and not clean separation between content vs UI.

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

I personally don't have much direct experience working with CMS before.

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

Your thoughts / comments on each of the options above, or if you have other solutions in mind not mentioned here, would be greatly appreciated! One of my challenge is that we need to make a really sound decision because whichever path we decide to go down with, we would likely be stuck with it, decision is not something that can easily be discarded and start over.

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

回答by Koen Peters

Personally I have some experience with Hippo and a lot with dotCMS. I do know a little about Alfresco, Liferay and Magnolia but I have not worked with them before. I have no experience whatsoever with Adobe CQ, because I never took the time investigating. This is because of the high costs being a no go for many of our clients. Alfresco is indeed a better solution if you're looking for an online document management system, which I think you aren't. You are right about Hippo, Magnolia and dotCMS being somewhat similar, which isn't that strange because they try to solve the same problem: being an Enterprise class Java based Web Content Management System. They focus heavily on managing the content which can be used in pages that are also manageable with the CMS.

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

To be honest: I have a bias towards dotCMS because I have worked with the systems a lot and know much about it. I thought I'd explain why it works for us so you can take that into consideration. I work in a Java shop that does a lot of middleware development for its clients using JBoss and the whole EE stack. We connect old (Cobol) and new systems together and put a shiny new web interface on top of that middleware that targets both admins and consumers. To be able to create these interfaces we need a CMS that does a few things well:

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

1. Java based (because we're a Java shop this enables us to have the same people work on the CMS and the middleware)
2. Horizontal scalable to tens of servers without too much hassle. In the classic case when scaling out to multiple servers the database and the assets folder are shared between the nodes. This could be a problem when you have many nodes, but in practice it's not such a big issue because most of the load will hit the index and not the db or the disk. In 2.5 and up dotCMS offers a "share nothing" mode where each node has its own database and assets folder, but this does requires you to use an additional (read: licensed) authoring server that pushes the content to each of the nodes. I have not played with this setup myself, but it sounds promising, especially because each node can be a simple and cheap box that only uses postgresql / mysql and tomcat and because there is no single point of failure anymore. In the classic case if the shared assets folder or the db would die all nodes would be down as well, except when you cluster the db and the disk as well which is expensicv to do. With this "share nothing" setup this is no longer the case. As I said: I have no experience with this, but it sounds like it might work.
3. Admin interface usable by both power users and non techie people (clients). Not everybody is "good with computers", but they too need to be able to manage the content (very often these people work in the marketing department of our clients). dotCMS offers ways to create admin interfaces that show only a few of the functionalities dotCMS offers. This prevents them for having to understand the whole system which speeds up training and acceptance.
4. Structured content. This is biggie. We want to be able to define many types of content all with a fixed set of fields, just like a database table. All without having to rebuild or restart the system. The people that would define content based on this structure (the name dotCMS uses for these types) cannot enter invalid data because the system protects against that. This makes building websites so much more future proof and convenient. Especially for developers.
5. Focus on content first. The first months that we used dotCMS we actually only used dotCMS for managing the content itself and exposing that through JSON API's. We did not use CMS features like defining templates and creating pages. This works fine and sounds like the stuff you're looking for. dotCMS has a JSON/XML Webservice that returns content based on queries. We use this a lot in almost all our projects, see here for more info: http://dotcms.com/docs/latest/ContentAPI. Using dotCMS itself for the whole frontend is also a possibility. Especially with the Spring controllers that it supports and the CSS-framework agnostic new template designer it is a nice way to build systems that require more than just some content.
6. Multilingual. dotCMS offers a few ways to do this. You can create content in all languages that you need, even non textual content such as images. Because of the "content first" approach many things are content in dotCMS , and can be treated as such, including creating a version for each language that you need.
7. Open source. dotCMS offers a community version that we use most of the time. Only for the pro features like load balancing, using oracle for the database, etc, a paid version is necessary. And even then the costs are manageable. See http://dotcms.com/products/editions/for more details about this.
8. Internal caching mechanism. Because of the high load some of the sites we have build need caching. DotCMS uses the Google Guava for their caching which works pretty well.
9. Extendability, also a biggie. We needed to be able to extend the functionality of dotCMS for obvious reasons. DotCMS used to only offer an old school way of doing plugins that is kinda ugly and is based on an ant script that overwrites the dotCMS classes with your own. It works fine, but I always feel dirty after writing such a plugin. However since version 2 they offer an OSGi based plugin framework that is pretty sweet and much more developer friendly. It went out of beta in the 2.5 version. We're planning to port all of our plugins to the new framework.
10. Multi host. We need to be able to host multiple sites within the same CMS. DotCMS provides this natively. It's also a nice way to share common stuff between multiple hosts which we use a lot.

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 过去只提供一种老派的插件方式，这种方式有点丑陋，并且基于 ant 脚本，该脚本会用您自己的类覆盖 dotCMS 类。挺好用的，但是写了这么个插件总觉得脏。然而，从第 2 版开始，他们提供了一个基于 OSGi 的插件框架，它非常可爱，对开发人员更友好。它在 2.5 版本中退出了测试版。我们计划将所有插件移植到新框架中。
10. 多主机。我们需要能够在同一个 CMS 中托管多个站点。DotCMS 本身就提供了这一点。这也是在我们经常使用的多个主机之间共享公共内容的好方法。

Of course there are also down sides. Here are a few:

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

1. Web CMSes like dotCMS store its content in a database and the assets as files on the disk. This makes versioning and synchronizing between different servers a pain in the butt. Starting from the 2.5 version dotCMS offers synchronizing tools that enable you to push content from one environment (for instance UAT) to another (for instance PROD), which helps. But not being able to checkout a single version of the content from something like GIT or SVN is very annoying. Especially since we as Java developers are accustomed to things like automated testing in a continues integration environment. Of course you can store the database as a SQL statement and the assets directory but that's slow and not so "nice". But then again all systems that store state in a database have this flaw.
2. DotCMS takes some time to learn. It's not a small CMS like Wordpress that you'll understand in one afternoon. It has many features and is very powerful, but you'll most likely need a day or so to understand the dotCMS way and then another couple of days to understand all the API's. I do encourage you to first read some docs and tinker with it before building a real production site: many ways lead to Rome, but some of them consist out of quicksand. :)
3. DotCMS is RAM hungry. To keep things fast it cached everything, so if you have a lot of content it will eat away at the RAM you have available. You can tweak this but it's easier to just give it enough RAM we have found.
4. Not all configurations of WebDAV + editing client are compatible with dotCMS. For instance on a mac I have found that you best use Cyberduck as a WebDAV client and Aptana as a text editor. Other setups do freaky things that dotCMS does not like much. You got to play a little to find out what the best setup is for you. I did find that if you file a bug on their githubthey get it fixed in the next release. They told me that WebDAV is hard to get right because it's not a fixed standard which I understand but it can still be a pain in the butt.

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 很难做到正确，因为它不是我理解的固定标准，但它仍然是一个痛苦的问题。

If you want to learn dotCMS read their -not so bad- documentation: http://dotcms.com/docs/latest/TableOfContentsand also take a look at their demo site (http://dotcms.com/products/demo/). In the demo site you'll find examples of all the concepts that dotCMS offers. Oh and check out our own free dotCMS plugins as well. Especially the JavaScript and CSS minifier is very handy: http://geekyplugins.com/.

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

Hope this helps a little. Let me know if you want to know more.

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

回答by Von Lion

Disclaimer: I work for Hippo, so I'll try to only answer with facts and not opinion :-)

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

1. Hippo is fully Java based, front end is language independent, but geared towards JSP or Freemarker, optionally you can use a REST-interface and use whatever.

2. Many plugins are created and collected at the Hippo forge.

3. Content-centric design has been a staple of Hippo development, should pose no issue.

4. Yes, by default all JCR calls are available. Apart from that you are able to define your own REST interface to suit your needs, example in the demo, documented here.

5. I dare say yes, in my experience most non-tech users find the interface easy to understand.

6. Multilingual is easy, part of the default multi-channel setup.

7. The community edition (which is complete, no bait-and-switch) is open source, there is some enterprise functionalitybehind a proprietary license. The license also opens up support avenues, besides the Google Groupand Stack Overflow.

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

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

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

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

5. 我敢说是的，根据我的经验，大多数非技术用户发现界面易于理解。

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

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

Now, on your comment about the documentation being incomplete, let me offer my opinion: You are right, the documentation is an ongoing struggle. Most stuff is documented, but is hard to find. We are working on improving the overviews, introductions and tutorials, but we are obviously not done yet. If you can't find anything, usually the community is able to help and point you in the right direction.

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