基于Java的CMS,具有RESTful服务/ API以访问内容

Question

对于那些可能因为"没有建设性而投票支持这个问题的人 - 目前看来,这个问题不适合我们的问答形式." - 如果你建议我应该在哪里发布这个问题(https://softwareengineering.stackexchange.com/？或任何以CMS为中心的论坛？)会很棒

之前曾提出过类似的问题:

• /sf/ask/64310571/
• /sf/ask/280406801/
• /sf/ask/580915331/
• /sf/ask/338625171/
• /sf/ask/135746691/

所有这些都已经有几年了,所以我想知道是否有新的建议/讨论.

一些背景:我们是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 Feed.

5. 需要有一个像样的用户界面,并且对业务用户来说越直观越好,因为我们可能被移动到平台的一些客户可能想要管理他们自己的内容

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有一点了解,但我之前没有和他们合作过.我对Adobe CQ没有任何经验,因为我从来没有花时间调查.这是因为很多客户的高成本是不可取的.如果您正在寻找一个在线文档管理系统,Alfresco确实是一个更好的解决方案,我认为您不是.你对Hippo,Magnolia和dotCMS有点相似是对的,这并不奇怪,因为他们试图解决同样的问题:成为基于企业级Java的Web内容管理系统.他们非常注重管理可以在CMS中管理的页面中使用的内容.

说实话:我对dotCMS有偏见,因为我已经对系统进行了很多工作并且对它有很多了解.我想我会解释为什么它适合我们,所以你可以考虑到这一点.我在一家Java工作室工作,为使用JBoss和整个EE堆栈的客户进行大量的中间件开发.我们将旧(Cobol)和新系统连接在一起,并在针对管理员和消费者的中间件之上放置一个闪亮的新Web界面.为了能够创建这些接口,我们需要一个能够做好以下事情的CMS:

1. 基于Java(因为我们是一个Java商店,这使我们能够让同一个人在CMS和中间件上工作)
2. 水平可扩展到数十台服务器,没有太多麻烦.在扩展到多个服务器的经典情况下,数据库和assets文件夹在节点之间共享.当你有许多节点时,这可能是一个问题,但实际上它并不是一个大问题,因为大多数负载将命中索引而不是数据库或磁盘.在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类的蚂蚁脚本.它工作正常,但在写完这样的插件后我总觉得很脏.但是从版本2开始,它们提供了一个基于OSGi的插件框架,它非常可爱并且更加开发人员友好.它在2.5版本中脱离了测试版.我们计划将所有插件移植到新框架中.
10. 多主机.我们需要能够在同一CMS中托管多个站点.DotCMS原生提供此功能.这也是在我们经常使用的多个主机之间共享公共内容的好方法.

当然也存在不利因素.以下是一些:

1. 像dotCMS这样的Web CMS将其内容存储在数据库中,将资产存储为磁盘上的文件.这使得不同服务器之间的版本控制和同步成为一种痛苦.从2.5版开始,dotCMS提供了同步工具,使您能够将内容从一个环境(例如UAT)推送到另一个环境(例如PROD),这有助于实现.但是无法从GIT或SVN这样的内容中检出单个版本的内容非常烦人.特别是因为我们作为Java开发人员习惯于在持续集成环境中进行自动化测试.当然,您可以将数据库存储为SQL语句和assets目录,但这样做很慢而且​​不那么"好".但是,所有在数据库中存储状态的系统都有这个缺陷.
2. DotCMS需要一些时间来学习.它不是像Wordpress这样的小型CMS,你可以在一个下午理解.它具有许多功能并且功能非常强大,但您很可能需要一天左右的时间来理解dotCMS方式,然后再过几天来了解所有API.我鼓励你在构建一个真实的制作网站之前首先阅读一些文档并修补它们:许多方式通向罗马,但其中一些是由流沙组成的.:)
3. DotCMS是RAM饥饿的.为了保持速度快,它会缓存所有内容,所以如果你有很多内容,它会占用你可用的内存.你可以调整一下这个但是给我们找到足够的RAM更容易.
4. 并非WebDAV +编辑客户端的所有配置都与dotCMS兼容.例如在mac上,我发现你最好将Cyber​​duck用作WebDAV客户端,将Aptana用作文本编辑器.其他设置做了dotCMS不太喜欢的怪异事情.你必须发挥一点,找出最适合你的设置.我确实发现,如果你在他们的github上提交了一个bug,他们会在下一个版本中修复它.他们告诉我,WebDAV很难正确,因为它不是我理解的固定标准,但它仍然是一个痛苦的屁股.

如果你想学习dotCMS,请阅读他们的-not so bad-文档:http://dotcms.com/docs/latest/TableOfContents 并查看他们的演示站点(http://dotcms.com/products/demo/).在演示站点中,您将找到dotCMS提供的所有概念的示例.哦,看看我们自己的免费dotCMS插件.特别是JavaScript和CSS minifier非常方便: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 外,该许可还开辟了支持途径.

现在,关于您对文档不完整的评论,让我提出我的观点:您是对的,文档是一个持续的斗争.大多数东西都有记载,但很难找到.我们正在努力改进概述,介绍和教程,但我们显然还没有完成.如果您找不到任何东西,通常社区可以帮助您并指出正确的方向.