Ruby on rails 门户的Ruby技术

我刚刚看到whitehouse.gov正在使用drupal作为CMS和门户技术。 drupal的一个优点似乎是添加插件很容易，而且编程是最少的，也就是说，重新发明轮子是最少的。这实际上正是RubyonRails的枯燥哲学。因此：

• drupal的缺点是什么
• Rails或其他基于Ruby的技术会取消哪些作为whitehouse.org（或其他CMS门户）门户技术的资格

---

主观上，我觉得Drupal管理界面有点笨重。您可以自己尝试，而无需在上实际安装Drupal。话虽如此，Drupal社区目前似乎有很大的发展势头，它开始成为一个真正功能齐全的CMS

---

比较Rails和Drupal有点像比较苹果和桔子。Rails是一个应用程序框架，Drupal是一个CMS（尽管包含一种应用程序框架）。

我是一名Rails开发人员，所以我完全支持Rails解决方案，但目前没有Rails CMS在功能和插件方面与Drupal这样的CMS接近

我把这部分归因于37signals倡导的“少即是多”的哲学

Wordpress、Drupal和其他人追求“尽可能多的功能”，这样做最终会吸引大量用户，他们会发现这些产品确实满足了他们的需求

---

和其他许多人一样，我一直在考虑启动一个基于Rails的CMS系统，该系统具有大量的功能和良好的插件架构。在客户端工作和我正在开发的托管应用程序的开发之间，还没有时间处理这个问题。

allesklar，Radiant中的扩展系统有什么问题？已经有很多Rails CMS了。我怀疑，与创建另一个利基CMS相比，为一个已建立的系统做出贡献以改进它对整个社区来说会更有成效。

我刚刚发现了这个网站：

drupal的缺点是什么

对于Ruby和Rails来说，这确实是一个相当主观的问题。Drupal是一个可靠的内容管理选项，在面向社区的网站上非常出色。它对于非门户网站的通用内容管理也很有用。缺点是它是建立在PHP之上的，如果你是一个Rubyist，那么这是一个很大的缺点。此外，如果你只关注核心，它是一个项目的野兽。API非常大，适合Drupal这样的项目，但这会使大量定制工作变成大量的编码工作。此外，由于Drupal的整个体系结构，数据类型没有明确的分离，除非您编写一个自定义模块来进行明确的分离，虽然这符合“Drupal方式”，但对于一些人来说，将所有内容都视为节点或Drupal分类系统的结构或诸如此类的内容是有点奇怪的

Drupal最大的缺点可以这样最好地概括：为了有效地使用Drupal，您确实需要以一种您对像Radiant这样的CMS系统所不了解的方式来了解和理解Drupal；但Radiant远没有Drupal那么复杂

Rails或其他基于Ruby的技术会取消哪些门户技术的资格 whitehouse.org（或其他CMS门户）

Rails与Drupal的不同之处在于，它根本不是一个真正的内容管理系统，而是一个更通用的应用程序框架。您可以以类似于Rails的方式使用Drupal，但Drupal实际上比Rails多得多。Drupal和say Radiant或BrowserCMS或其他一些Ruby/Rails CMS包之间可以进行更好的比较。目前有Ruby/Rails门户系统，但很少有能与Drupal及其社区的大部分系统相匹配的。Ruby生态系统中最具可比性的选项只与Drupal所能做的部分相匹配，但这是因为Drupal是一个庞大的项目和社区。Drupal是一种瑞士军刀加上一些在网上做网站的工具。Ruby没有一个真正类似的项目，因为大多数Ruby开发者看不到任何复制Drupal腰围的理由

如果您正在考虑使用Ruby代替Drupal，我建议您考虑以下项目（大多数Ruby项目的覆盖范围比Drupal小，但更符合您站点的实际需要）：

---

如果您正在寻找Ruby中构建的门户技术，则需要考虑一个相对较新的候选对象。EngineY最初是作为一个社交网络框架构建的，但它的一些特性使它成为一个可行的传统门户网站。EngineY的“小部件”概念类似于传统门户的portlet。EngineY中包含一个托管内容小部件，可用于创建由托管内容组成的门户。最重要的是，EngineY得到了积极的维护，并且每天都在不断发展和改进。

解决笨重问题的方法是首先安装“管理”菜单模块，这确实起到了很大的作用。谢谢您提供的信息！好的，我明白了，drupal是一种成熟得多的技术，而rails CMS仍然必须从早期的适配器拉到更大的CMS项目中。