drupal - 什么时候不使用 Drupal 节点？

Question

我最近创建了一个非常简单的 CRUD 表，用户在其中存储了一些数据。对于数据，我创建了一个自定义节点。该功能非常适合使用基本节点功能在 CRUD 表中创建、编辑和删除数据(实际上，我很惊讶使用少量代码通过适当的访问控制对基本功能进行编程是多么快速和容易) ……

由于数据不应该被视为与“内容”相同的方式，例如博客文章(没有标题，没有正文，没有评论，没有修订，不应该出现在 ?q=node 页面上，没有预览，没有预告片等)...我发现我大部分时间都在“关闭”并修改drupal自动为节点执行的内容。

我知道这是一个品味问题，但是应该在哪里划定什么应该被视为节点，什么不应该？换句话说，不使用节点从头开始编程这些东西会更好吗？

Answer 1

除了简单的编辑/更新/删除功能之外，为自定义数据使用节点还有很多额外的好处:

通过分类的可能分类

通过作者跟踪隐含的“所有权”

创建/修改时间的隐式跟踪

默认情况下基本访问控制，可通过大量模块进行扩展

通过 View 灵活的查询生成/列表/过滤

通过 CCK 字段

可能的临时扩展/注释

工作流、 Action 等的可能定义

大量的钩子(Hook)以编程方式拦截/调整几乎每个使用方面/场景

所有贡献的模块提供的评论、投票、评级和大量其他功能，这些模块在节点上/与节点一起工作......

鉴于这一切，我想说你需要一个很好的理由不使用节点在 Drupal 中存储数据。节点只是 Drupal 生态系统中几乎所有东西的基本构建 block ，与 yield 相比，删除一些不需要的默认“功能”的开销似乎很小。

也就是说，处理与节点系统分开的数据的一个可能原因/论据可能是该数据是否直接旨在注释其他节点(想想分类法)。但是，由于您可以轻松地从其他节点引用节点(关于如何执行此操作有很多不同的选项)，所以这个论点并不强。

另一个(更强大的)论点是 数据完整性 - Drupal 在规范化、关系数据存储、引用完整性、事务处理和其他相关主题方面不是很强大(礼貌地说)。如果您有这方面的需求，您可能别无选择，只能跳过节点概念并自行在系统内创建和维护一个单独的数据岛。