关于这里的评论,我认为 Plone 不会那样工作(至少现在不会了)。
1 - Plone 确实比其他 CMS 解决方案慢,但从开箱即用的设置到 Apache-Varnish-Zope-Relstorage 解决方案,有很多优化空间。
2 - 这是真的。这里的答案有点解释它,但确实 Plone 是一种复杂的动物。
3 - 不确定你的意思。TAL Path 表达式基于对象属性遍历的概念。对我来说似乎是OO。
4 - 对。尽管在您了解了 Acquisition 的工作原理之后,它不会妨碍您。我猜,在 Plone 中没有多少东西依赖于 Acquisition。
5 - 不正确。Zope 页面模板都是关于将内容与演示分开的。可以从 ZODB 查看内容和演示文稿(实际上大多数模板都保留在文件系统中,您只是在 ZODB 中看到它们的“视图”)这一事实与 ZODB 是一个大对象这一事实更相关数据库 - 这反过来并不意味着它们都是内容。“纯” OO 系统中的一切都是一个对象,重要的是对象的种类(表示对象、内容对象等)。
6 - Plone 确实区分了网页设计师和内容创建者。设计师进行所有自定义(模板、CSS、JS 等),然后内容创建者使用 Plone UI 创建内容。这里的重点是 Plone 主要是一个 CMS,这意味着内容创建者在设计方面应该是外行。
7 - 部分正确。考虑到 UI 结构不会改变,所有的表现规范都包含在 CSS 文件中。如果 UI 结构需要更改,设计师可能会与程序员合作 :-) 以充分利用模板。
我猜在没有输出动态页面的系统中,设计师可以完全自由地只说 HTML、CSS 和 JS,而忽略一些其他技术,无论是 PHP、Python、ASP 还是 Java。如果他这样做了,那么肯定会有一个程序员从设计师那里得到 HTML、CSS 和 JS 并“动态化”。这个模型肯定存在于 Plone 中。