5

我们正在研究基于 java 的 CMS（是的 java，我们正在远离脚本语言）。

任何人都亲身体验过 Magnolia 和 Jahia 的社区版，制作模块更容易，您的整体体验是什么？

  • 对于内容编辑
  • 对于开发人员（制作模块）
  • 处理更改请求有多容易（您可以将这个或那个添加到页面 foo/bar）

房车

4

7 回答 7

3

免责声明：我是 Jahia CTO。我希望 StackOverflow 标准可以接受这个答案，否则请让我现在，我会改进它。我首先想作为对答案的直接评论来回答，但这似乎不可能。

我只想解决 GKrost 列出的缺点，因为其中一些不再很准确（因为这是写的，所以至少发布了 Jahia 的一个主要版本），而另一些则不正确。

Jahia 缺点：

JCR 似乎是大型（超过 10000 个页面，> 50000 个内容元素）网站的瓶颈，尤其是在使用 mysql 时。捆绑的 Java-In-Memory-DB 速度更快。

实际上，JCR 与此无关，因为它只是一个规范。您正在谈论底层 JCR 实现，在本例中为 Jackrabbit。虽然很难超越诸如 HSQLDB ( http://hsqldb.org ) 之类的内存数据库的性能，但也不建议在生产中使用这样的数据库，因为它不是为企业设计的部署，例如集群环境。不推荐的另一个原因是它会占用与 CMS 相同的 JVM 上宝贵的堆空间，随着数据的增长，这将成为问题。

至于大小限制，10000+ 页面确实是一个相当大的站点，大多数安装很少达到这个大小，但如果他们做到了，有多种方式来分发数据。10000+ 也是一个限制，主要适用于 Jahia 6.5 和更早版本的 CMS，但现在很有可能超过这个限制。至于 50000 个内容元素，这个限制是不正确的。我们已经部署了包含更多内容的安装，但确实，内容设计结构对于确保不会引入瓶颈很重要，但对于任何 CMS 甚至是 ElasticSearch 等必须正确分片的技术都是如此设法避免性能问题。

Jahias Lucene 版本已过时

Jahia 的默认 Lucene 版本实际上是底层 Jackrabbit JCR 实现使用的版本。从允许开发 OSGi 模块的 Jahia 7 开始，可以在您自己的包中嵌入另一个版本的 Lucene 甚至 ElasticSearch，而不会干扰 JCR 后端所需的那个。据我所知，这在诸如 Magnolia 之类的非 OSGi CMS 中是不可能的（但对于使用基于 OSGi 的 Web 框架的 Apache Sling 的 Adob​​e 是可能的）。

当开发自己的应用程序/模块时，你必须使用 JSP，你不能使用 JSF（Jahia 计划集成 Spring Webflow，但你永远不知道是否以及何时......）

实际上，您可以使用 JSP/Groovy/Velocity 或 Java Scripting API 支持的任何语言。Spring Webflow 集成在 Jahia 7 中，现在可用，所有管理模块都使用 Spring WebFlow 完全开发（http://www.jahiaone.com/home/program/session/MVC-in-Jahia7-Using-SpringWebFlow） . 对于 JSP，我们提供了强大的标签库，无需任何脚本即可轻松开发视图，因为我们自己的大多数视图都不包含 Java 代码。JSF 集成也应该是可能的，但不是开箱即用的，需要很好地理解如何将 JSF 集成到现有的 servlet 控制器中。

在反应时间方面，支持是减慢速度的方式

这是不正确的。我们的 SLA 非常明确，我们一直尊重它们：http ://www.jahia.com/services/technical-assistance 。然而，总支持时间也取决于客户的回答速度。

有时需要数周时间才能修复严重错误

这在 2 年前曾经是这种情况，但从那时起，我们已经建立了每月一次的修补程序发布系统，并且在出现安全问题的情况下会加速发布。

无法导出/导入历史版本；唯一的方法是从底层数据库手动复制东西

这确实是设计使然。大多数导入/导出操作旨在不处理版本，因为它们最常用于将预生产环境迁移到生产环境，或者相反。并不是说如果在导入同一对象时存在内容对象的版本，它们将不会被删除。虽然可以使用 JCR 导出版本，但这不是开箱即用的。出于备份目的，我们建议在系统级别进行备份。

Jahia 旨在作为集群工作，但它不能复制用户会话。这意味着，当他们通过身份验证的集群节点出现故障时，用户必须重新登录。

这不再是真的，但曾经是。在 Jahia 6.5 之前，我们的会话是不可序列化的，但现在已经不是这样了。所以这主要是应用服务器配置的一个限制，默认情况下没有配置为复制会话。在现实生活中，这不是（很多）问题，因为集群节点故障不应该发生，并且当它们发生时，会出现较小的限制。

集群节点必须共享数据库和文件系统。您不能对数据库进行集群。Jahia 不支持（技术上）MySQL 集群。（背景：他们将索引放在 MySQL Cluster 不支持的 BLOB/CLOB 上）

我也不认为这是正确的。我只是仔细检查了我们在 MySQL 上设置的所有索引，我们没有在 BLOB/TEXT 或任何长版本上设置任何索引。此外，在我们的大多数集群部署中，客户通常更喜欢使用 Oracle，因为它更适合此类解决方案。Jahia 还支持其他强大的数据库，例如也支持集群的 PostgreSQL 或 Microsoft SQL Server。

一般文档有改进空间，JavaDoc/Source文档基本不存在

我同意这一点，文档总是可以改进的，我们一直在努力。我们的 JavaDocs 可在此处获得：http: //downloads.jahia.com/downloads/jahia/digitalfactory7.0.0/digital-factory-root-7.0.0.0-javadoc/源代码文档是我们一直在处理的。

社区薄弱；jahia 论坛中的大部分答案来自 jahia 员工。

然而，这在很大程度上是正确的，但与此同时，我们的许多集成来自不幸的是没有时间或机会参与的合作伙伴。这就是为什么 Jahia 员工在空闲时间回答但大多数问题都能得到答案，这毕竟是一件好事，你不觉得吗？当然，我们一直在寻找新的方法来扩展我们的社区，我们的第一次用户大会 JahiaOne 超出了我们最乐观的预测。在论坛上，我认为添加每月摘要是一件好事，因为目前没有用户回来的动力。

没有可用的公共模板（来自 jahia 的模板除外）

那里没有评论。我们提供了一些尽可能通用和完整的默认模板，但我们欢迎所有贡献。

于 2014-05-23T08:54:39.337 回答
1

贾希亚优点：

  • 可用于基于 Java 的 CMS 的最佳用户界面/后端/管理
  • Jahia 不断改进他们的产品
  • 易于安装并使小型站点启动并运行
  • 由于 JCR，在定义自己的结构时非常灵活

Jahia 缺点：

  • JCR 似乎是大型（超过 10000 个页面，> 50000 个内容元素）网站的瓶颈，尤其是在使用 mysql 时。捆绑的 Java-In-Memory-DB速度更快。
  • Jahias Lucene 版本已过时
  • 在开发自己的应用程序/模块时，您必须使用 JSP，而不能使用 JSF（Jahia 计划集成 Spring Webflow，但您永远不知道是否以及何时......）
  • 在反应时间方面，支持是减慢速度的方式
  • 有时需要数周时间才能修复严重错误
  • 无法导出/导入历史版本；唯一的方法是从底层数据库手动复制东西
  • Jahia 旨在作为集群工作，但它不能复制用户会话。这意味着，当他们通过身份验证的集群节点出现故障时，用户必须重新登录。
  • 集群节点必须共享数据库和文件系统。您不能对数据库进行集群。Jahia 不支持（技术上）MySQL 集群。（背景：他们将索引放在 MySQL Cluster 不支持的 BLOB/CLOB 上）
  • 一般文档有改进空间，JavaDoc/Source文档基本不存在
  • 社区薄弱；jahia 论坛中的大部分答案来自 jahia 员工。
  • 没有可用的公共模板（来自 jahia 的模板除外）
于 2013-02-14T11:49:07.893 回答
1

去年，我们不得不自己做出这个选择。我们安装了 Jahia 和 Magnolia，经过全面比较后，我们选择了 Magnolia。尽管两者相似，但对于开发人员而言，在 Magnolia 中制作模块比在 Jahia 中更容易。在 Magnolia 中，自定义是通过编辑 jsp 模板来完成的。在 Jahia 中，它更复杂，因为开发人员必须创建支持 Java 类，然后编译和部署该类，等等。

选择 Magnolia 后，我们对内容编辑器的易用性和性能感到非常满意（Magnolia 将预先压缩页面并将其存储在缓存中以提高性能。）您可以在此处查看生成的站点：www.franchiseprocess .com。您看到的所有内容都基于内容编辑器可以修改的 magnolia 模板。

于 2011-02-01T18:27:59.397 回答
0

以下是我在 Apache Roller 邮件列表中提出的一个相关问题对 Jahia 的一些反馈：

http://web.archiveorange.com/archive/v/PxZtPQyYMTldSEuEePMb

于 2011-01-29T19:15:09.327 回答
0

我们选择了 Jahia 而不是 Magnolia。

  • 明确的角色分离：网站管理员、模板编辑、开发人员、贡献者、编辑
  • 易于创建模块，因此以干净的方式扩展 Jahia
  • 编辑模式非常酷，在页面上拖放组件
  • 并不是很贵。企业支持大坝好
  • 他们的带薪培训很好

缺点： - 社区似乎很小 - 没有那么多在线文档，论坛不是超级活跃 - 需要培训才能开始

于 2013-02-13T00:42:22.530 回答
0

现在我们和Jahia一起去了。给出的原因是，看起来网站的编辑部分看起来更好，内容编辑器也更容易。我自己也觉得制作新模板、添加 jQuery 并在 Jahia 中工作更容易。

使用 Magnolia，我一直觉得我是在直接编辑内容存储库（比如在 pgAdmin 中编辑数据库表），而 Magnolia 中的“树”没有告诉我我所做的是否好，这涉及到很多猜测。我可以填写无效值，而 magnolia 会毫无问题地接受这一点。

Jahia 体验更新：到目前为止，我们对 Jahia 感到非常满意。目前，我们在单个服务器上运行它，大约 4000 个用户没有问题。使用我们当前的数据集，速度也不是问题。jahia 的支持非常好，比其他人几周发布的更好，我通常会在 1-2 天（根据合同规定为 3 天）得到官方支持，当我在 Skype 上 ping 一些 Jahia 时，通常在一小时内，他们是非常友好的人。

于 2011-02-25T20:22:45.413 回答
0

JCR 的问题在于没有很多关于优化的技术文档。在大多数情况下，JCR 将胜过任何 RDBMS。但是，熟悉层次结构并知道您的子节点不应超过 1000 个（因此要构建层次结构），这一点很重要。我正在为 JCR 中超过 400 万用户掌握个性化数据。

从这个角度来看，Magnolia 的设置更好，因为一切都构建在 JCR 中。Magnolia 作为 Web 应用程序实例运行，并且很容易将内容从一个实例部署到另一个实例。Magnolia 就是我们所说的“以内容为中心”的 CMS。这意味着内容直接在页面上进行编辑，并直接在该页面上出现。当然，可以创建所谓的“查找内容”，即在 Web 层次结构之外的一个地方创建的内容，但在网站的多个地方重复使用（也称为“软引用内容”）。

Jahia 绝对是一个非常有趣的解决方案，但必须依赖 RDBMS（因此是不必要的集成依赖）对于企业解决方案来说是一个很大的“弊端”。扩展也不容易，而使用 Magnolia，我可以在任何给定时间设置一个新的“发布”（或“渲染”）实例，从而提高性能和安全性（故障安全）。

于 2013-02-23T17:16:14.470 回答