Django 与 Grok / Zope3 与 Pylons
我是一名受过培训的计算机程序员，但已经离开网络开发一段时间了。我正在对各种 Python Web 开发框架进行一些背景研究。我知道 Django、Grok / Zope 3 和 Pylons 都是很好的可靠框架，但在后台使用它们的方式很少。有人可以向我解释一下每个框架方法的差异，以及与其他框架相比，其中一个框架的亮点在哪里？
我的具体用例是构建一个 Web 应用程序，该应用程序将根据用户提供的各种信息向用户推荐产品。因此，需要大量的用户输入，例如基本资料、产品偏好、尝试在用户之间建立社交关系。它还需要支持员工将带有标签功能的产品上传到系统中，然后将这些功能与用户进行匹配。
关于最后一点，Plone 的某些部分是否有助于为非技术人员提供上传产品和产品描述的界面？ Plone 容易借用吗？似乎我不必重新发明轮子，让人们可以上传待售/推荐的物品以及一些描述物品的元数据。感谢您的帮助。
I am a computer programmer by training but have been away from web development for a while. I am doing a little bit of background research on various Python web development frameworks. I understand that Django, Grok / Zope 3, and Pylons are all good solid frameworks, but have little in the way of background working with them. Can someone explain to me the difference in approach of the each of the frameworks, and where one shines when compared to the others?
My specific use case is in building a web application that will recommend products to users based on a variety of user supplied information. Thus, it will take a fair bit of user input in the shape of a basic profile, product preferences, attempt to establish social relationships between users. It will also need to support staff uploading products into the system with labeled features that can be then matched to users.
On the last point, would parts of Plone help with providing an interface for non-tech people to upload products and descriptions of the products? Are piece of Plone easy to borrow? Seems like I shouldn't have to reinvent the wheel in terms of having a way for people to upload items for sale / recommendation along with some metadata to describe the items. Thanks for the help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
根据您的背景和要求，我建议您使用基于 Django 的 http://pinaxproject.com/ 之类的东西。
Pyramid（Pylons 的后继者）是一个非常低级的框架，您需要选择库或自己编写所有应用程序代码。对于有经验的人来说，这是有道理的，并且可以让您完全控制您的代码。但如果您从头开始并且不熟悉可用的库，那么这会是一个障碍。
Django 和 Grok 都是高级框架，其中 Django 是更受欢迎的选择。如果您还不熟悉使用对象数据库或 URL 遍历，那么学习 Grok 会更耗时。
Plone 不适合您的用例。它是一个内容管理系统，而不是一个通用的 Web 框架。它使用的库很少可以在不同的上下文中重用，当然它的 UI 也没有。如果您想通过个性化内容提供引人入胜的用户体验，那么 Plone 不适合您 - 这不是它的构建目的。
免责声明：我是 Plone 和 Zope 2 / Zope Toolkit 的发布经理，并且使用过 Pyramid，但没有使用过 Django。
Based on your background and requirements, I'd advise you to go with something like http://pinaxproject.com/ which is based on Django.
Pyramid (the successor to Pylons) is a very low-level framework and you need to either choose the libraries or write all your application code yourself. For someone experienced this makes sense and gives you full control over your code. But it is a bit of a hurdle if you start from scratch and aren't familiar with the available libraries.
Django and Grok are both high level frameworks, with Django being the more popular choice. If you aren't familiar yet with using object databases or URL traversal, Grok is more time consuming to learn.
Plone is not suited for your use-case. It's a content management system and not a general web framework. Very little of the libraries it uses can be reused in a different context, certainly none of its UI. If you want to provide an engaging user experience with personalized content, Plone isn't for you - that's not what its been build to handle.
Disclaimer: I'm a release manager for Plone and Zope 2 / Zope Toolkit and have used Pyramid but not Django.
Dolmen 项目 是一个构建在 Grok 之上的 CMS。很简单，但是用的人很少。如果您使用 Grok，您就可以重用 GUI。
但正如 Hanno 所说，Grok 比 Django 更耗时学习。而且 Django 的用户数量远多于 Grok。
使用 Grok 的优点是您几乎可以从 Zope 组件架构中受益，而无需编写 ZCML 并使用装饰器。
使用 Pyramid/Pylons，您将获得一个非常简单的框架，仅此而已。它是一个解耦框架，所以你可以自由使用任何你想要的模板引擎（Mako、Genshi、Jinja、Cheetah），你可以自由选择 sqlalchemy、zodb、mongoDb 等，你也可以自由选择 url映射方案（遍历与 django 风格的映射或两者的组合）。如果需要，您也可以在这里使用 ZCA。对于初学者来说，这可能会变得非常混乱或冗长。
Django 是一种整体框架，为您提供一种做事的方法。这就是为什么它很容易学习并且是一个非常好的选择。但是，根据我的经验，有时你会想要偏离 Django 标准，而如果不修补一堆东西就根本无法做到这一点。
而且，对于 Zope3，我建议您下载 BlueBream 的副本，看看它如何为您服务。
Dolmen project is a CMS built on top of Grok. Is very simple, but there are very few that use it. If you go with Grok, you could be able to reuse the GUI.
But As Hanno said, Grok is more time-consuming to learn than Django. Also Django has far more users than Grok.
The advantage of using Grok is that you can profit from Zope Component Architecture almost without writing ZCML and using decorators instead.
With Pyramid/Pylons you get a very simple framework and nothing else. It is a decoupled framework, so you are free to use whatever templating enginge you want (Mako, Genshi, Jinja, Cheetah), you are free to choose sqlalchemy, zodb, mongoDb, etc., and you are also free to choose the url mapping scheme (traversal vs. django-style mapping or a combination of both). You can also use ZCA here if you want. For starters this might become quite confusing or verbose.
Django is a kind of monolithic framework that gives you one way to do stuff. That's why it's easy to learn and a very good option. But, in my experience, you sometimes get to a point where you want to deviate from Django standards and it simply cannot be done without patching a bunch of stuff.
And, as for Zope3, I'd recommend you to download a copy of BlueBream and se how it does for you.
作为一名 Plone 用户，我可以说在 Plone 中创建内容对象很困难。关于如何执行此操作的文档不多，而且很复杂。有些人建议使用 UML 和专门的 Plone 产品来使其更容易，但这又引入了另一种依赖性。
我提到内容对象的问题是因为您的“产品”（与 Plone 产品不同）可能会在 Plone 中表示为您需要自己编写的内容对象。
当用户和编辑以新闻文章、新闻稿、照片等形式输入和批准文本时，Plone 是最好的选择。在这种情况下，此类内容有预定义的内容对象，因此不需要自己编写它们。
——乔纳森·马克
As a Plone user I can say that creating Content Objects in Plone is difficult. There is not much documentation on how to do it and it is complicated. Some recommend using UML and specialized Plone products to make it easier but that introduces yet another dependency.
I mention the problem with content objects because your "products" (not the same as a Plone product) would probably be represented in Plone as a content object which you would need to write yourself.
Plone is best when users and editors are entering and approving text in the form of news articles, press releases, photos etc. When that is the use case there are predefined content objects for such things so one does not need to write them oneself.
--Jonathan Mark