什么可以证明 Plone 的复杂性是合理的？
Plone 非常复杂。 Zope2，Zope3，五，ZCML, ZODB、ZEO，一大堆缩写词和缩写。
万事开头难，目前的状态似乎还没有定论。 它主要基于 Zope2，但通过 Five 合并了 Zope3。 XML 配置文件随处可见。
陡峭的学习曲线值得吗？ 这种复杂性在今天仍然合理吗？
背景：我需要一个平台。 客户通常需要 CMS。 我目前正在阅读“专业克隆开发”，没有Plone 的先验知识。
问题是：客户并不总是想要相同的东西，而且你无法事先知道。 有一点是肯定的：他们不想要 Plone 的默认主题。 但任何附加功能都是有风险的。 你不能只是开始说“如果你想看Plone 的复杂性，你必须要求它。”，当你不了解系统足以进行计划时。
Plone is very complex. Zope2, Zope3, Five, ZCML, ZODB, ZEO, a whole bunch of acronyms and abbreviations.
It's hard to begin and the current state seems to be undecided. It is mainly based on Zope2, but incorporates Zope3 via Five. And there are XML config files everywhere.
Does the steep learning curve pay of? Is this complexity still justified today?
Background: I need a platform. Customers often need a CMS. I'm currently reading "Professional Plone Development", without prior knowledge of Plone.
The problem: Customers don't always want the same and you can't know beforehand. One thing is sure: They don't want the default theme of Plone. But any additional feature is a risk. You can't just start and say "If you want to see the complexity of Plone, you have to ask for it." when you don't know the system good enough to plan.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
如果没有任何背景信息，很难回答你的问题。 如果您只想要一个博客，那么复杂性是否合理？ 否。如果您要为 400 多人构建公司内部网，那么复杂性是否合理？ 是的。 如果您想成为一名顾问，这是一项不错的投资吗？ 绝对地！ 那里有很多 Plone 工作，而且它的薪水比一般的 PHP 工作要高得多。
我鼓励您澄清您正在尝试构建的内容，并向 Plone 论坛寻求建议。 Plone 有一个非常成熟和友好的社区——如果你想做的事情不适合 Plone，它绝对会让你知道。 当然，您可以使用 Plone 做任何您想做的事情，但在某些领域它是可用的最佳解决方案，而在其他领域则需要做大量工作才能将其更改为其他功能。
一些背景：
Plone 此时复杂的原因是它正在转向更现代的架构。 它现在正在弥合新旧方法，这增加了一些复杂性，直到过渡基本完成。
Plone 这样做是为了避免破坏向后兼容性而让客户落后，他们对此非常重视——与我可以提到（但不会；）的其他系统不同。
您关心您的数据，Plone 社区也关心他们的数据——即使我们正在过渡到新的架构，我们也希望您能够升级到新的、更好的版本。 这是 Plone 社区的优势之一，但是在飞行过程中修改飞机当然要付出代价，而且这是暂时的、额外的复杂性。
此外，Plone 作为一个社区非常注重安全性（将其与所报告的漏洞的任何其他系统进行比较），以及重视良好架构、测试和可重用性的非常专业的文化。
举个例子，考虑当前正在开发的 Plone 版本（将成为 4.0）：
——Alexander Limi，Plone 联合创始人（略带偏见；）
It's hard to answer your question without any background information. Is the complexity justified if you just want a blog? No. Is the complexity justified if you're building a company intranet for 400+ people? Yes. Is it a good investment if you're looking to be a consultant? Absolutely! There's a lot of Plone work out there, and it pays much better than the average PHP job.
I'd encourage you to clarify what you're trying to build, and ask the Plone forums for advice. Plone has a very mature and friendly community — and will absolutely let you know if what you're trying to do is a poor fit for Plone. You can of course do whatever you want with Plone, but there are some areas where it's the best solution available, other areas where it'll be a lot of work to change it to do something else.
Some background:
The reason for the complexity of Plone at this point in time is that it's moving to a more modern architecture. It's bridging both the old and the new approach right now, which adds some complexity until the transition is mostly complete.
Plone is doing this to avoid leaving their customers behind by breaking backwards compatibility, which they take very seriously — unlike other systems I could mention (but won't ;).
You care about your data, the Plone community cares about their data — and we'd like you to be able to upgrade to the new and better versions even when we're transitioning to a new architecture. This is one of the Plone community's strengths, but there is of course a penalty to pay for modifying the plane while it's flying, and that's a bit of temporary, extra complexity.
Furthermore, Plone as a community has a strong focus on security (compare it to any other system on the vulnerabilities reported), and a very professional culture that values good architecture, testing and reusability.
As an example, consider the current version of Plone being developed (what will become 4.0):
— Alexander Limi, Plone co-founder (and slightly biased ;)
如果你想看到Plone的复杂性，你就必须提出要求。 对于大多数人来说，它不存在。 它通过一键安装程序在几分钟内安装完毕。 然后一键登录，一键创建页面，使用所见即所得编辑器，然后一键保存。 一切都通过直观的 Web GUI 进行。 克隆是一种产品。
如果您想将其用作“平台”，那么该平台是超过一百万行代码的堆栈，它实现了完整的内容管理套件。 没有人知道这一切。 然而，所有这些“首字母缩略词”和“文件”都是软件的证据，该软件被分解为组件，因此没有人需要知道一切。 您可以根据需要深入或浅入其中。 如果您在内容管理的某些方面需要某些东西，它已经存在，您不必从头开始创建它，并且可以按照与广泛实践和审查一致的方式来完成它。
If you want to see the complexity of Plone, you have to ask for it. For most people, it's just not there. It installs in a couple of minutes through a one-click installer. Then it's one click to log in, one click to create a page, use a WYSYWIG editor, and one click to save. Everything is through an intuitive web GUI. Plone is a product.
If you want to use it as a "platform," then the platform is a stack of over one million lines of code which implements a complete content management suite. No one knows it all. However, all those "acronyms" and "files" are evidence of a software which is factored in components so that no one need know it all. You can get as deep or shallow in it as you need. If there's something you need for some aspect of content management, it's already there, you don't have to create it from scratch, and you can do it in a way that's consistent with a wide practice and review.
我在此处发现了一条匿名评论，这比该帖子本身要好得多，所以我将其全文重新发布到这里，并纠正了一些拼写错误。
今年夏天，我的国际象棋俱乐部要求我制作一个新网站，董事会成员应该能够在其中添加新闻快报、文章……听起来像 CMS。 作为一名 Python 开发人员，我查看了 Plone 并购买了 Aspeli 的《专业 Plone 开发》一书（顺便说一句，写得非常好）。
我花了三周的假期来研究这本书并设置了该网站的第一个模型。
三周后我意识到 Plone 有一些非常好的东西，但也有一些非常令人沮丧的东西
从积极的一面来看，
缺点
我认为 Plone 之所以如此缓慢，是因为第 4、5、6 和 7 点。
第 6 点和第 7 点让我放弃了 Plone。 我四处寻找其他选择，最终决定在 Pylons 上开发自己的 CMS，与 Plone 相比，它的速度快得惊人。 在同一台开发服务器上，我的启动时间为 1 秒，并且重新加载页面时间无法测量。
网站 www.kosk.be 正在运行（荷兰语）。 其背后的 CMS 名为 Red Devil，将从明年开始作为一个单独的开源项目启动
I found an anonymous comment here which is much better than that post itself, so I'm reposting it here in full, with a couple of typos corrected.
This summer my chess club asked me to make a new website, where the members of the board should be able to add news flashes, articles, ... Sounded like a CMS. Being a Python developer, I looked at Plone and bought the Aspeli book Professional Plone development (excellent written btw).
I took 3 weeks of my holiday the study the book and to setup a first mock up of the site.
After 3 weeks I realized that Plone has some very nice things but also some very frustrating things
On the positivie side
On the downside
I assume that Plone is so slow because of points 4, 5, 6 and 7.
Points 6 and 7 made me dropping Plone. I looked around for other options and eventually decided to develop my own CMS on Pylons, which is blazingly fast compared to Plone. On the same development server I have a startup time of 1 second, and a reload page time is not measurable.
The site www.kosk.be is running (it is in Dutch). The CMS behind it, named Red Devil, will be launched as a separate open source project beginning next year
我认为有四件事可以证明在使用 Plone 上投入时间是值得的：
过去某个时候已经做过了。 他可能问了一些问题并得到了帮助
答案，或者他写了一个教程。 通常这会留下很容易找到的痕迹。
关于他是如何做到的。
减少。 Plone过去已经证明它能够自我更新并抛弃旧的
以干净的方式构建基础设施，并定义弃用阶段。
哦等等，有人告诉我克隆开发者会议是最好的会议之一！
就像那个
I see four things that can justify an investment of time in using Plone:
already did at some time in the past. He probably asked some questions and got helpful
answers, or he wrote a tutorial. Usually that leaves traces easy to find.
about how he did it.
reduced. Plone has proven in the past that it is able to renew itself and drop old
infrastructure in a clean way with defined deprecation phases.
Oh wait, I was told the plone developer meetings are one of the best!
Like that one
从系统管理员的角度来看，Plone 还算不上是绝对的魔鬼。 在 Linux 平台上，升级、维护和安装在你想要安装的地方都比必要的更加痛苦。 不过，这只是我的两分钱，也是为什么我通常更喜欢避免使用 Zope/Plone 堆栈。
注意：新版本更好，但旧版本......呃
From a system administrator standpoint, Plone is just shy of being the absolute devil. Upgrading, maintaining, and installing where you want to install things is all more painful than necessary on the Linux platform. That's just my two cents though, and why I typically prefer to avoid the Zope/Plone stack.
Note: it's better with newer releases, but older releases.... ugh
吸积。
Accretion.
关于评论这里我认为Plone没有像那样工作（至少不再是）。
1 - Plone 确实比其他 CMS 解决方案慢一些，但从开箱即用的设置到 Apache-Varnish-Zope-Relstorage 解决方案，有很大的优化空间。
2 - 确实如此。 答案这里解释了这一点，但确实克隆人是一种复杂的动物。
3 - 不确定你的意思。 TAL 路径表达式基于对象属性遍历的概念。 对我来说似乎是OO。
4 - 正确。 尽管在您了解了获取的工作原理之后，它仍然不会妨碍您。 我想，在 Plone 中，没有多少事情依赖于获取。
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中肯定存在。
About the comment here I think Plone doesn't work like that (at least not anymore).
1 - Plone is somehow slower than other CMS solutions indeed, but from the out-of-the-box setup to a Apache-Varnish-Zope-Relstorage solution, there is a lot of optimization space.
2 - That is true. The answer here kind of explains it, but indeed Plone is a complex animal.
3 - Not sure what you mean. TAL Path expressions are based on the concept of object attribute traversal. Seems OO to me.
4 - True. Although after you understand how Acquisition works, it stays out of your way. And in Plone not many things depend on Acquisition, I guess.
5 - Not true. Zope Page Templates are all about separating content from presentation. The fact that content and presentation can be viewed from the ZODB (and actually most of the templates stay in the filesystem, you just see a "view" of them in the ZODB) is more related to the fact that the ZODB is a big object database - which in turn does not mean that they are all content. Everything in "pure" OO system is an object, it is just the kind of object (presentation objects, content object, etc) that matters.
6 - Plone does distinguish between webdesigners and content creators. The designers do all customizations (templates, CSSs, JSs,etc) and then content creators create the content using Plone UI. The point here is that Plone is mainly a CMS, which means that content creators are supposed to be laymen in terms of design.
7 - Partially true. Considering that the UI structure won't change, all presentation specification is contained in CSS files. If the UI structure needs to change, the designer might work with a plogrammer :-) to adequate the templates.
I guess in no system that outputs dynamic pages the designer is completely free to speak only HTML, CSS and JS, and leave out some other technology, be it PHP, Python, ASP or Java. If he does, there will be definitely a programmer that will get the HTML,CSS and JS from the designer and "dynamize it". This model definitely exists in Plone.
如果不需要，请不要使用它。 整个 ZOPE 宇宙就是一只恐龙。 由于年代久远，已经积累了很多残渣和铁锈。 如今，很多事情都会完全不同。 对于大多数东西来说过于复杂，对于复杂的东西来说很难处理。 这与纤薄且可扩展的设计相反。 为了认真解决这个问题，我认为该项目没有必要的人力。
对不起，我的言语有些过激，我也希望它能更好。
Don't use it, if you don't have to. The whole ZOPE universe is a dinosaur. Grown for ages, has collected lots of cruft and rust. Many things would be done completely different nowadays. Overly complex for most stuff, hard to handle for complex stuff. It's the opposite of slim and scalable design. And for seriously fixing this, I don't see the necessary manpower involved in the project.
Sorry for the harsh words, I also wish it would be any better.