Programmers, don’t use CCK or Views.
UPDATE: So it looks like Views/CCK is moving into core. This is good and bad. Good because everything in core is extremely solid — core code gets that special love from a large body of Drupal contributers that third-party modules don’t typically see. Bad because I think it could result in more jerry-rigged nodes and resulting messy queries for many users. Still, the argument can be made that if you prefer to write your own SQL queries, then it’s possible that Drupal as a framework is too much overhead for you and you should look for alternatives. I’m going to set up some CCK/Views functionality on this site and see if the code has improved, because there are a few things I like about CCK/Views. For example, the fact that CCK handles files upload/preview (a pretty intensive task if you choose to DIY outside the ‘File Attachments’ field), and that Views has a pretty decent integration API.
DISCLAIMER: This item was written shortly after a long few days of trying to reconcile some custom code with nodes that were written in Views — for that reason, it’s fairly critical. In Views/CCK’s defense, if your needs are simple, they can fulfill them quickly and easily. Keep that in mind while reading the following.
Can you write an SQL query? Yes?
Then stay far away from CCK and Views.
These are *great* modules for people who have simple needs and little programming experience. They’re also adequate for people who have programming ability but are working on a smaller site and only needs the “1 or 2 extra options” a client has requested for each node. They’re also very cleverly written — i’ve borrowed/stolen/revised a number of pieces of code from the Views UI module when I was trying to realize a particular form layout.
However, they’re terrible binds for anyone who has a working understanding of relational databases and is planning on doing any custom work whatsoever.
The php-executable-code option also encourages unmaintainable code (ever tried to track down a display conditional that someone stored in a database field?). While I respect the fact that this opens up a lot of customization options that would otherwise be unavailable, I’d submit that if you need that level of customization, and you can write code, you shouldn’t be sticking it in a textfield and submitting it. If you can’t write code, you should be working with a properly written extension for Views/CCK instead of pasting in a snippet that Joe Blow wrote in a comment somewhere.
I could go on — in CCK, select definitions do not encourage INT keys (which makes sense for probably 95% of select lists — oh, and by the way, that Yes/No select option you built? It’s being stored in a LONGTEXT field), if there’s no keys and someone realizes the usefulness of HAVING an INT key tries to add one, keys aren’t auto-updated (this is a large oversight, imo — how would you like to invalidate all your data with one change?), select options often get forced into a many-to-one relationship (meaning extra table joins) for no discernible reason, Views and taxonomy generates queries that make me cry, it’s very easy to build a view that tries to insert a serialized array that’s larger than a MEGABYTE (that’s over a million characters — like sticking ‘The Old Man And The Sea’ a single field) into your database (which, when my co-worker hit save, caused our server with 4GB RAM to present the always lovely “MySQL has gone away!” note).
There are a couple things that are probably difficult to build for even an experienced drupal developer — a great example is uploading images WITH preview — but if you plan on writing ANY custom code at all, I would avoid the temptation to shortcut with a CCK and Views solution. Sure, prototype it, but plan a FULL rewrite if your prototype does not meet your needs — no, ‘just one little hack’ to get that feature complete.
Anyone who has to work on your code later will thank you for it.
