views:

58

answers:

2

I've recently created a very simple CRUD table where the user stores some data. For the data, I created a custom node. The functionality works great for creating, editing, and deleting data in the CRUD table using the basic node functionality (I'm actually amazed how fast and easy it was to program the basic functionality with proper access controls using only a tiny bit of code)....

Since the data isn't meant to be treated the same way as 'content' such as a blog post (no title, no body, no commments, no revisions, shouldn't show up on ?q=node page, no previews, no teasers, etc)... I find that I'm spending most of my time 'turning off' and modifying the stuff that drupal does automatically for nodes.

I know its a matter of taste, but where should one draw the line on what should be treated as a node and what shouldn't? In other words, would it be better to program this stuff from scratch without using nodes?

+3  A: 

It helps to think also that a node doesn't need to be public either. Some nodes are private/internal and can be controlled further with access controls. The way you are doing it, whatever you're doing, makes all the scalability and extending it on your shoulders.

I would probably approach it with CCK/Taxonomy depending on what I was doing. That way, I get the added benefit of Views/Panels/etc module integration without writing any additional code.

Kevin
Can you elaborate on what you mean by 'private/internal' nodes. Are there any examples you can point to?
stotastic
Not all Drupal content has to be public on a website. It depends on what you are trying to do. For example, if it doesn't need a body, disable that field in the content type. If it doesn't need a title, implement Automatic Node Titles module and it will hide it. You can disable comments for node types. To disable node or /?q=node you can change the frontpage in Site Information.
Kevin
@stotastic Eventhough nodes are the main content on a site, it doesn't mean that everybody can access them. With different modules, you can create different access rules based on taxonomy node types etc. When you keep the nodes, you get the power that every module that work with nodes, will work with your CRUD table, without needing to do any extra work. This can also be a great time saver.
googletorp
+5  A: 

Using nodes for custom data has quite some additional benefits besides easy edit/update/delete functionality:

  • possible categorization via taxonomy
  • implicit 'ownership' via author tracking
  • implicit tracking of creation/modification time
  • basic access control by default, expandable by a huge selection of modules
  • flexible query generation/listing/filtering via views
  • possible ad hoc extensions/annotations via CCK fields
  • possible definition of workflows, actions and the like
  • a huge number of hooks to programmatically intercept/adjust almost every usage aspect/scenario
  • commenting, voting, rating and tons of other functionality provided by all contributed modules that work on/with nodes ...

Given all this, I'd say you need a very good reason to not use nodes to store data in Drupal. Nodes are simply the fundamental building blocks for just about everything in the Drupal ecosystem, and the overhead of removing some unwanted default 'features' seems pretty small in comparison to the gains.

That said, one possible reason/argument to handle data separate from the node system might be if that data is directly aimed at annotating other nodes (think taxonomy). But since you can easily reference nodes from other nodes (with lots of different options on how to do this), the argument is not to strong.

Another (much stronger) argument would be data integrity - Drupal is not very strong (to put it politely) concerning normalized, relational data storage, referential integrity, transaction handling and other related topics. If you have requirements in that direction, you might have no choice but to skip the node concept and create and maintain a separate data island within the system on your own.

Henrik Opel

related questions