cck vs. own module

If you want to create a content type that is just like a story or just like a page or just like a blog, then creating a content type module is very easy. It is as easy as copying, for example, the file story.module, renaming it to {your-content-type}.module and doing a find and replace with "story" and {your-content-type} MORE or LESS in that file.

As a newbie I was able to create a new content type called short_story in about 5 minutes, by creating a module.

I didn't like CCK because it displays a title for each field and the textarea field wasn't flexible enough for me.

However CCK is useful when you want an assortment of different fields for a content, one being an integer, another a phrase, another a date, another text, etc.

Caroline

robertgarrigos, I understand what you are saying as its something i think about all the time. Developing your own (relatively complex) module isn't an easy task as i have found out. It isn't that drupal doesnt support custom module development well, its just that getting all the information and especially tutorials is very hard. I spend alot of time trying to understand the ins and outs of drupal by browsing through all the drupal hooks in the API documentation but alas it is a difficult task. If however you are looking for basic fast creation of node and such, the CCK module is fantastic! For me however its lack the ability to really create something special. As far as i know when you create custom node types in the CCK and you want these nodes to relate to other nodes, you can only achieve a 1-1 and 1-N relation. I on the other hand want to create a module that supports a n-n relation in my table. I havent figured out how to do this just yet but for me it means creating a custom module.

Feedback is appreciated

Hi Robert,

Interesting topic..

I pondered the same question recently, i.e. what is the reason that would make a developer to choose to write his own module instead of using cck?.

The conclusion I came to is that it's far better to run with CCK rather than develop your own modules.

The main reason was because I tend to develop for other people on contract and a key factor during the handover stage of a Drupal project is that the project is independent of me.

In other words, if I created custom modules, instead of using CCK, the project owner is really tied to coming back to me for updates/ammendments/improvements/upgrades. Where as if I used well-support modules, it's much easier for them to D.I.Y. changes or find another Drupaller to tweak it for them.

It's not impossible for them to find a Drupaller that can dive into someone else's code, but, invariably, especially with tight deadlines and creating custom modules, there is bound to be something unusual that can confuse another Drupaller. Let's face it, when most are creating/tweaking modules for themselves, many don't comment and document for themselves as they go along. So while it's not impossible to jump in to someone else's code, I would tend to try and stick with Drupal core with well supported modules instead.

Another, bigger picture, factor is that it keeps the patch/updates alive on drupal.org. i.e. If it was encouraged to create a custom module for every new variation required by a client, the patch que would be empty, modules would never improve and the real value chain Drupal offers falls down.

The only negative aspect I considered was the memory factor...i.e. it maybe more memory efficient to use slim and trim custom modules rather than the cck suite and add-ons. Having said that, I have worked on some music sites that had huge peaks in traffic and using cck.modules didn't hinder that at all. There wouldn't have been much value in using custom modules instead.

The handover aspect overrides all the possible values in saving a bit of memory. Consider how much smoother it is for a client, using cck rather than custom modules, to upgrade their site when a security announcement flies into their email box or if they, for example, want to enjoy some of the new version features?

That's just my 0.02 cents......

Dub

Well it's easy... CCK is a recent module and now it has been added in a simplified version in the core.
Some people prefer to keep their modules updated some discontinue them in favor of cck.

------------------------------------------------------
Be Smart, Think Free, Choose OpenSource.

The points posted above a good ones but for me the real issue is how the CCK works. My aim with drupal is not aonly to use it as a cms but i am extremely interested in getting this stored information from the database and exporting it to third party applications (analysis applications to be precise). Now, if i create my own module i will have alot more control on how the module interacts/inserts data into my database but as i have found with CCK, this isnt so simple. The way i see it from a database structure view (and im sure not everybody will care) is that CCK makes it very hard to get at the data maybe using an ETL tool and exporting it elsewhere. This could be of course because of my lack of knowledge with the drupal database schema but i have never yet worked with such a hard structure. Anyone out there understand it better than i do? ;)

Best regards

Interesting topic, Drupal offers two(2) excellent options to create custom nodes:
- Custom modules
- CCK

I wish there was a table/chart that compare/score the options:
Database access(speed), Performance, Memory usage, Export/Import, Ease of Install, Ease of Use, Upgrade Path, etc.

----
Darly

and refrain from creating full blown node modules unless necessary, regardless of whether the administrator will need manage the content fields on her own or not.

And if I need some extra functionality I usually create a module to define a new CCK field type instead of a new independent module. I have found it's easier for the developer and I can reuse functionality easier.

It depends on the extra functionality you need, though. I have found this approach works well when I want to show information that I must request from a web service based on a parameter that is the value of one of the fields of my node.

Is any of this wholly custom node module development going on in Drupal 5? I would greatly appreciate pointers to the resources or base module people use.

And count Agaric Design in for any and all efforts to make programmatic CCK easier and the use of CCK extensions in custom modules, for two routes for the better of all possible worlds!

~ben

People Who Give a Damn :: http://pwgd.org/ :: Building the infrastructure of a network for everyone
Agaric Design Collective :: http://AgaricDesign.com/ :: Open Source Web Development

The Übercart uses modules to create custom node types, specifically products, because it's easier to distribute a node type module than a script that sets up CCK node types with all the required fields. It is possible to do it that way. The latest release uses the Image field and image cache to store product images, so they needed to be enabled automatically. I can't expect everybody who downloads Übercart to set up image fields the same way as everyone else no matter how good the instructions are. This also ensures that people are using the exact same product module, barring their own customizations.

I think the answer to the original question involves the number of sites that are going to use the new node type, and the complexity of functionality. If all the node is supposed to do is contain content, then CCK is great. If it's a one-time thing for a specific site, CCK is great. If the node has to interact with various and sundry other modules in and of itself (products added to a shopping cart, selectable attributes, etc.) then CCK doesn't work and you need a custom module.

This, I think, is the main difference. CCK is what you need when nodes don't have to do anything.

Modules also allow you to package together non-node functionality in with the node type. Every kind of hook can be implemented in a single module: custom blocks, user interaction, taxonomy. For a single site, you can do all of these things separately, even if their related in some way. But the next time someone wants a very similar thing, you have to make everything from scratch again. With a module, you just plug it in and teach them how to use it.

-----
Übercart -- One cart to rule them all.

I've been looking at CCK vs. custom module for a site where I have several content types which relate to each other, and I want to have a particular page which shows related fields from more than one content type.

e.g. I have a Venue content type (with Name, Address, Website Address fields) and an Event content type (with Event Title and Date fields and using a node-reference field to indicate Venue). I want a page which lists Events, but which also includes the Web Address of the Venue.

I thought it would be easiest to create my different content types with CCK, and then write a custom module to create the page.

This was very easy to write and worked fine - UNTIL I then defined another content type which also used the Web Address field. This caused CCK to move the Web Address field from the content_type_event table into its own table called content_field_web_address. OK, that's fine - that's how CCK works. But it means that the SQL queries in my custom module are now all wrong!

So in other words, I have lost the easy expandability of CCK, because whenever I add another content type (or, presumably change or remove one), I'm in danger of messing up my custom module.

Is there any kind of API to CCK that allows you to make SQL queries without having to know exactly where CCK is storing a particular field?

Lucy C

Just a few days ago, I put more info about ROLLED OATS out there.

OK, this is my module, and it's time for debugging. This module may actually be a replacement for CCK on one level, while some backend parsimony may be applied to data bodies that the form delivers.

I find that by switching to using the OAT package, or perhaps some other javascript toolkit, much of the input type validation can be done at the client. And many of the fields can be placed in the one body field of the form. Further, I can begin to create a repository of fields that are stored in a DB and rendered as JS and HTML components.So, the forms go to the DB and server much less.

Some validation of data requires a server. But, with AJAX, there is no need to involve Drupal in quering up services such as credit card lookup, unless of couse you want to. The result has to go back to the form as validated or not prior to the final form submission (or POST or GET). Javascript is designed to stop the faulty form from going. Furthermore, Javascript with it's AJAX part, can delay the form submission until secondary server validations have completed their asynchronous call backs. So, there is no need to embed these queries into a custom field handler that goes along with custom field tables, etc.

Here is another interesting feature of the ROLLED OAT. I found that by using the repository of OATS, and the OAT kit from openlink, I had less code required to handle the interactions with the fields and the Data. So, now I about as much of the functionality I want for taxonomy form field management with just a little bit of code. So, by taking a different approach to handling the data and the form management, there is now less code to maintain. Futhermore, I find that the code for new field types is easier to write. I add to the ROLLED OAT repository, and there is a field available to add into any point of a taxonomy. And, if I conform to a few simple guidlines, the fields add their validation checks, data formatting, and visual presense in a way that seems as if they almost as if they did it themselves.

How does the ROLLED OAT package yield up the form interface? Well, every rendered part of a page from drupal, via drupal_render, requires that the module presenting a form or even other objects be checked for a subroutine, theme_, with the form elements as a parameter. So, I have made at least one routine theme_rolled_oats_, e.g. rolled_oats_tab_set, and theme_rolled_oats, for general purpose ones. The rolled oats theme type has it's own types, which are names of elements in a repository. So, you can put these into a PHP routine for making a form, or you can let the module rolled_oats_content execute a generalized version of operations determined by editing the content type with the content definition form.

So, should you write your own module? Help me get this one working. Otherwise, it was a few intense weeks of staring at it all for a while, giving each line a few long lapses of time. You might want to do that yourself. But, I could use some help.

I think what is at issue here is the dependency on a server and DB to do a certain amount of work, while javascript toolkits are evolving rapidly. Perhaps small devices will require that not too much javascript will be used. But, I really think that they are just getting more powerful with more memory, color screens, etc. Soon cell phones will be like CRAY's and we'll all run Manhatten when we message our friends. So, I don't think CCK would want to remain to intimintly tied to the server as time progresses. As such, it will have to change at some point. But, you can have ROLLED OATS today , or in a few.

Must run to a movie... Need some debugging. Need to get back to this. And, I want to emphasize coexistence. So, later. Please comment this or put a comment on www.classydex.com

Thanks....

what if you need a multipage form and need to save the result on every step/page and not just after all the pages has been completed. I also need to use the availability module on my form. availability module becomes a collapsible block when you add it to a content type. what I need is to make the availability block appear only in one step/page. I have tried cck witch which allows multipage cck but add on modules like availability appears on all the steps/pages. Moreover the cck witch currently cannot save info by step/page. You have to go through all the steps/pages to save the info.

I also have other fields like google maps which is also needed in the new node type.

So, which do you think is better tweak cck/cck witch? or create a custom node type via a module?

If I create a custom node type, can I possibly reuse/invoke cck fields? which means can i use the imagefield module for instance so i don't have to code the image file uploads anymore? is there a way to hook to the cck fields from a custom content type module?

thanks very much in advance.

Hi,

Hope someone can direct me to some examples so I can cut and paste.

I have a custom module I copied.

I would like to create this using cck programmatically so I can get the freebies that cck throws in, like node_import and others, instead of recreating all the methods that work for cck.

Could someone please point me in the right direction as to how to program a cck module.

I'm not sure if its in the *.install file. An example would be great to cut and paste from.

Is it possible to make a cck programmatically in during a module install. ie. not a install profile but during a module creation process but calling the cck create functions?

cheers