什么时候不使用Drupal节点?

时间:2010-06-17 14:04:36

标签: drupal drupal-6

我最近创建了一个非常简单的CRUD表,用户可以在其中存储一些数据。对于数据,我创建了一个自定义节点。该功能非常适合使用基本节点功能在CRUD表中创建,编辑和删除数据(我实际上惊讶于使用适当的访问控制只使用一小段代码来编写基本功能的速度和简便性) ....

由于数据的处理方式不同于“内容”,例如博客文章(没有标题,没有正文,没有通知,没有修订,不应该出现在?q =节点页面,没有预览,没有预告片等)...我发现我花了大部分时间'关闭'并修改drupal自动为节点做的事情。

我知道这是一个品味的问题,但应该在哪里划清应该被视为一个节点的东西,哪些不应该?换句话说,在不使用节点的情况下从头开始编程这些东西会更好吗?

2 个答案:

答案 0 :(得分:6)

除了简单的编辑/更新/删除功能外,将节点用于自定义数据还有其他一些好处:

  • 可能通过分类法进行分类
  • 通过作者跟踪隐含'所有权'
  • 隐式跟踪创建/修改时间
  • 默认情况下基本访问控制,可通过大量模块进行扩展
  • 灵活的查询生成/列表/通过视图过滤
  • 通过CCK字段进行的临时扩展/注释
  • 工作流程,行动等的可能定义
  • 以编程方式拦截/调整几乎所有使用方面/场景的大量钩子
  • 评论,投票,评级以及所有在节点上工作的所有贡献模块提供的其他功能......

鉴于这一切,我要说你需要一个很好的理由使用节点在Drupal中存储数据。对于Drupal生态系统中的几乎所有内容,节点只是 的基本构建块,而且与增益相比,删除一些不需要的默认“功能”的开销似乎相当小。

也就是说,处理与节点系统分离的数据的一个可能原因/论点可能是该数据直接针对注释其他节点(想想分类法)。但是,由于您可以轻松地从其他节点引用节点(对于如何执行此操作有许多不同的选项),因此参数不强。

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

答案 1 :(得分:3)

也有必要考虑一个节点也不需要公开。一些节点是私有/内部的,可以通过访问控制进一步控制。你正在做的事情,无论你做什么,都可以实现所有可扩展性,并将其扩展到你的肩上。

我可能会根据我正在做的事情用CCK / Taxonomy来处理它。这样,我可以获得Views / Panels / etc模块集成的额外好处,而无需编写任何其他代码。