Welcome to my corner of the web. Here you'll find my ramblings about faith, church, drupal, Geeks and God (my podcast), and my other unrelated interests.

While you can subscribe to all posts here from the Subscribe link on the right, there are two other main feeds. There is the drupal and other technology feed along with the faith and church feed.

Drupal Without Nodes

Posted on: Tue, 2008-01-08 20:25 | By: matt | In:

Every drupal site or app I've built has used nodes for the content/data objects. I've now come upon a few projects where the data already exists in it's own table structure and needs to remain that way. My first thought was to look at a development framework like symfony or cakephp. I have to use PHP and these are two good php frameworks. But, I'm starting to consider drupal 6 as the web framework for these projects.

My initial hesitation with using drupal was a large overhead when compared with the these other frameworks. If feels more heavyweight. But, these projects are going to call for forms (I'd love to use FormsAPI here), cron jobs, AHAH and AJAX, user management and permissions, session control, caching, and a number of other things drupal does.

I'm going to do a bit of testing of symfony vs drupal to see what comes up. But, before I do that I'm wondering if anyone has any experience with using drupal as a web framework without nodes. If so, were the results good? Is drupal on the heavy side without nodes?

Comments

#1 Other alternatives

Matt, I've also looked in the past at the Zend Framework as an alternative to Cake or Symphony for this kind of stuff (and been fairly well impressed with the little I've done with it). I keep coming back to Drupal for most projects though, partially because I'm familiar with it and with the API and able to be productive without a lot of ramp-up learning a different API.

-Jason

#2 code ignitor

Matt,

Our central web services dept has been using code ignitor. It looks pretty cool too..

http://codeigniter.com/

Shrop

#3 Sorta used it

I'm working on a project now in Drupal 5 where we do have some nodes, but the bulk of the data is coming from a 3rd party system via SOAP. We're not writing to it, but are reading from it. I've also had to integrate a lot of forms into designs that are extremely not-forms, visually, as far as Drupal is concerned. :-)

You can do it, and I'm actually rather happy with the results overall. Form API makes a fairly nice framework all on its own, even if you aren't using nodes. (Although doing file handling in Drupal without going through a CCK field is still a pain in the ass, at least in Drupal 5. I've not tried Drupal 6 yet for that.) The catch is that to do really off-beat visual forms, where you're integrating forms and readable data, you have to *really* know how to bent FAPI and the theme system. I've learned a lot just by figuring out how to make this thing work. :-)

It also helps a great deal if you can build a good thin data model atop the legacy data, whether Node-ish or not. Active Record, ORM, something else, doesn't matter as long as you abstract yourself away from the SQL as much as possible. It saves a lot of time.

If I were give a web app, rather than a CMS site, I don't know that I'd always use Drupal for it but Drupal would be a very strong contender. That's in part because I know it well, and in part because it is a fairly good, although by no means perfect, app framework in its own right; it's just a very CMS-oriented app framework.

#4 Zend Framework

I do agree with Larry. The ZF is definitely a nice Framework. It's based on the MVC-Pattern which makes the software very easy to maintain.
The downside is, it takes some time to wrap your head around (even more so if you are not familiar with OOP).

#5 Drupal without nodes is fun!

You can still utilize all of the other subsystems that you mentioned, and if you need to get the benefits of the nodeapi system (say you want comments, or uploaded files, or fivestar) with your non-node data, you can try using a proxy-node pattern where you generated nodes to represent the legacy data. Then you can instantly extend your legacy data with CCK, for example.

#6 Two ideas come to mind

1. Drupal lite. See related http://drupal.org/node/52286 and http://www.google.com/search?q=drupal+lite

2. Implement your foreign data type as nodes in drupal by doing your foreign data's CRUD operations in nodeapi. This is how old-school drupal contrib modules created 'event' node types etc. Part of this could involve assessing what a Foreign Data API for drupal would look like and do.

#7 ditch the drupal

you said you're stuck to the php, but if your looking to start subtracting lots of things from drupal then maybe you should start looking from the other direction and making up something from scratch.

Ruby on Rails! its is fast to get something together, its modular, and best of all ruby makes programming fun.

alright, sorry; that wasnt productive ;)

#8 Use everything except the node system

I have been working on a webapp that needed to import big amounts of data (tens of thousands of rows) in various formats, fast (minute-scale, not hour-scale). Then do calculations on it.
The first thing that comes to mind when you're looking at this problem from a Drupal-perspective is: create your content types with CCK, use computed field for the calculations.

That'd be nice. Only:
1) it would haveway too much overhead
2) importing would be kind of bitchy, since you have to do tricky things if you're working with nodes

Now, I convert the import files to SQL, then let MySQL import it. This way, I can import about 20,000 records in 30 seconds (including the time to conver the files to SQL, and it was tested on a normal pc, not a beefy server).

The main downside in my use case: you can't use Views, because it can only use the node table as the base table. Views 2 will do away with that restriction though! :)

P.S.: which module do you use for the "Save my Comment Information for next time" feature on your comment forms?

#9 Comment Info Module

The save my comment info for next time feature is the comment info module. The 3.x version of the module is a backport of the feature as it is built into drupal 6.

#10 No nodes is actually practical

Much like Larry, I've set up a back office application on Drupal 5, which has only a few nodes, and the bulk of the data is imported.

In that specific case, we import directly from CSV, OOo and other XML files, from Drupal, uploading to a set of non-drupal tables, and work from there while taking advantage of the services provided by Drupal for everything. The neatest thing being that I even added support for drupal indexed search over this set of non-drupal data: this allows fine-grain search tuning, since you control how the search crawler actually sees your data.

Pages are then built from these data, using the Zend Framework classes for every non-Drupal access.

So, in short, yes this is something that works quite well, and can be vastly more efficient than importing all content as individual nodes, notably for large volumes of small, often updated data like inventory and price lists.

#11 The joy of modularity

Folks who really know what they're talking about have already implied it, but to say it straight:

The heaviness of the node system is done away with by... not using nodes. (Hence, why comments still aren't nodes in Drupal.)

So I think the answer to "Is drupal on the heavy side without nodes?" is no.

#12 Don't immediately discount using nodes ...

Matt-

I'm glad to see somebody bringing up this issue. The work I do with Drupal doesn't usually relate to its community aspects at all. I typically do data-driven apps which require heavy, heavy form management and generation.

For this, I use Drupal + Qcodo (http://qcodo.com). I wrote (and am in the process of rewriting) a bridge layer between Drupal and Qcodo called 'QDrupal'. Imaginative name, yeah?

In a nutshell, the latest version defines a new node type that simply executes a file on the disk. A developer then edits that file to create their form using their favorite editor. The big gains though are in using Drupal for all the user management, access control based on nodes, help documentation, clean url's, plus any other Drupaly things you may need. All of this WITH the power of a PHP framework that was designed to build your heavy data management forms.

As far as speed ... I've honestly found that Drupal is much quicker then the frameworks I've used in the past. So much engineering has gone into Drupal over the years that I trust it much more as a piece of code then anything else, probably in the entire PHP universe.

If you're interested, I'd love to chat with you about what you're looking for in such a system to see how close QDrupal is to what you really need.

#13 External Data

Matt-

I do this presentation at (most) every DrupalCON.

http://ken.therickards.com/2007/03/24/oscms-xml-mashups-and-drupal-as-pl...

http://ken.therickards.com/2007/09/12/drupalcon-modules/

There are a number of ways to use Drupal with data stored in an external system -- including creating nodes on the fly using 'lazy instantiation.'

IMO, it would be faster to develop in Drupal simply because the other pieces are available (registration, theming) and done already.

#14 Its very doable

We did this by using Robert Douglass' hybrid approach (see above comment by him).

We pulled a unique id from the legacy db and then mass created nodes that had one CCK field - uniqueid. The using D5 multiple database support we simply use the nodeapi hook to load in data from the other database into the node using uniqueid.

So, we have nodes, yes, but they are really just proxies as he suggests that keep the uniqueid for looking up data in another database.

But we get all the node goodies - views, cck, search, etc.

#15 Did you write a custom module?

This sounds like a great approach. Would you mind providing a few more details?

Did you write a custom module to implement this?

How did you go about mass creating the nodes that point to the other database? Is that a custom script that sits alone on the server, and cron runs it regularly?

#16 2 Ways

This would have to be written as a custom module.

You could mass create the nodes when you first build the system.

Keeping up with new content as it's added if there's an outside system that accesses the same information would be a problem. In this case I can think of 2 ways to handle updating your nodes to point to the other system.

One way is to do an update on a cron job. I'd run the cron job very regularly.

The other way is to look something up as a node. If it doesn't find it the next step is to see if that thing is in the outside system. If so create a pointer node.

I'm sure there are more ways to skin this cat. I'm currently looking at using the zend framework ORM in drupal. Though, you'd loose some of the fun of the drupal node system.

#17 Drupal as a Framework

Except for a few websites that I maintain, I used Drupal mainly for the menu system (dispatcher) and Form API. Everything else on the db was put on a seperate postgresql schema not related to any of drupal tables. And my application got ACL for free ;)

I'd really like the idea of Drupal lite where it only have let say .. menu system, form api and ACL. That's enough to kickstart your new application by just writing *.module, put it under sites/*/modules, enable it in the admin and now you have a full application complete with user registration, login and ACL.

#18 I totally agree with you. I

I totally agree with you. I see Drupal as a complete framework with built-in elements, such as ACL and so on.

I'm currently developing an entreprise portal which is supposed to have, amoung other capabilities, project management functionnality.

I'm hesitating concerning the data management. As a developer, I prefer to use APIs instead of CCK-Views. But I don't know if I have to use drupal node system with other tables, to maintain specific data or to enterily manage my data in specific tables.

I'm considering the fact that in the first option (node + extra tables), I will have the number of rows in database multiplied by 2 (node table + my own table).

What is the advantage to use Drupal node system on managing my data only in my tables ?

#19 Drupal, as a set of APIs, is

Drupal, as a set of APIs, is a viable choice as a framework for developing powerful web apps.

#20 If feels more heavyweight

If feels more heavyweight. But, these projects are going to call for forms (I'd love to use FormsAPI here), cron jobs, AHAH and AJAX, user management and permissions, session control, caching, and a number of other things drupal does.
watch movies online