Do you think I should use cck or write my own custom node using node_example.module?

One person wrote on a thread that surely writing your own module is quicker than figuring cck out. That makes sense to me. I've had a lot of trouble trying to get cck to work.

I do not know php. Yesterday I began modifying node_example.module (available in api docs) to add my own fields and to theme the output. I was making good headway and learning a lot about how Drupal and php work. To me this is a big plus in writing my own node versus using cck.

also
It seems to me cck is still undergoing major changes and if I have my content in cck it may be prone to bugs or upgrade problems. (Flexinode users have been left behind in 4.7 since it's not fully updated.) With a simple module that I understand I presumably could upgrade it myself to 4.8.

On the other hand, perhaps in modifying node_example.module I may introduce security issues or scalability issues that I am ignorant of.

Also cck may have better interfaces with other modules.

The 2 custom nodes I want to write are (1) a review module. (Think for example, a restaurant review.) and (2) a listing module (Think for example, a listing of a house for sale.)

It seems to me quite a few programmers are using cck when they certainly are capable of writing their own node modules.

Opinions and advice are appreciated.

Comments

mfredrickson’s picture

I really must recommend CCK for your purposes. It would be much easier than managing your data yourself.

In my mind the central question as to whether to write a module yourself, or to use CCK is:

Do I have to manipulate the data behind the scenes?

If yes- make your own module
If no- use CCK

From your description, I think CCK fits your needs better.

Here is a quick setup for resturant reviews.

Create one CCK type called Resturant. Fields might include, name, location, price level, whatever.
Create a second CCK type called Resturant Review. One field should be node refererence to a "Resturant" node. Then when users create a review, they can just grab a resturant from the drop down list. Neat, huh?

Power like this makes CCK a great choice for a lot of applications.

--
http://www.ppmnsaction.org

mwu’s picture

interesting. thank you!

m, do you know anything about scalability? does cck do an inner join for every field like flexinode does?

mfredrickson’s picture

I'm still puzzling my way through the CCK code. I'm trying write some inport/export/save/create APIs for it. I don't exactly know the answer to that question. I think CCK stores all the fields for a specific content type in a single table, so it doesn't need to join for the fields. I could be wrong about that. I'll try to update this thread if I do get an answer to that question.

-M

mwu’s picture

thank you. please do.

but if cck stores the fields for a content type in one table, that would be a table for it in mysql right? i couldn't find one.

mfredrickson’s picture

I have a contact type called "My test node type".

In mysql:

describe node_content_my_test_node_type;
+---------------------------------------+------------------+------+-----+---------+-------+
| Field                                 | Type             | Null | Key | Default | Extra |
+---------------------------------------+------------------+------+-----+---------+-------+
| vid                                   | int(10) unsigned |      | PRI | 0       |       |
| nid                                   | int(10) unsigned |      |     | 0       |       |
| field_an_integer_check_box_fiel_value | int(11)          |      |     | 0       |       |
+---------------------------------------+------------------+------+-----+---------+-------+
3 rows in set (0.00 sec)

I see that CCK stores the field settings in different tables, but these are only important on node creation and content type editing, so there should not be a performance hit when viewing nodes (a much more common activity).

mwu’s picture

okay I've done some experimenting. This is what I found:

some fields are together
some are not

the main content type holds the regular text fields, the select text fields, the number text field (I only tried one number type)

checkboxes are not
url fields are stored elsewhere.

I guess that's why they say cck is better than flexinode but not as good as
a custom node for scalability. I'm interpreting the info correctly, right?

Just to clarify, you mean this only matters when the user edits the content (vs admin edits content type), right?

abaryudin’s picture

Sounds quite cool, actually.
--
http://www.baryudin.com