I confess that my 12 year affair with Drupal was more hate than love. While I loved the things I could do with Drupal I hated how it had to be done. Wordpress was like a bad first date that never ends, always disappointed and unsure about what will happen next. Rather that writing organized list or beautifully worded blog post I am just going to write some lines on each point I disliked and then flow it up with one or two lines about how the Content Connection Kit does not have those problems mentioned.
So CCK will have many of the developer features of Drupal. Just designed and coded differently without the fancy semantics and built in magic. Without the alphabet soup of design patterns and "standards" acronyms,"for the enterprise" posturing. Starting with:
Wordpress: custom "post types" is never what you expect when using the GUI and adding fields is best done with code. Finding things later is always a pain and the sites themes always seems to self destruct when anything is customized using the post types. WP is just not built to handle this.
CCK: I made sure that there is a single click functionality for adding content types an adding fields to those types. If you want to add more detail later you can but eight clicks in CCK means you've created a content type and added seven fields to it. I made sure that CCK is built on content types and fields from the very beginning.
Drupal: delete the content type and the data is deleted. Delete the field and the data is deleted. This because the database schema in Drupal sucks. While the group at Drupal and Acquia have always had inventive programmers, the database is and always has been the weakest point of design. Maybe it's that no one interested in databases has ever worked on the project, for Acquia or their ideas get killed.
CCK: delete the content type and the data remains until garbage collected or recycled in to another content type. The same thing applies for content and fields. The CCK content system has Types, containers and fields that are loosely coupled and a I wrote the code to support the database schema rather than compromising both with complex solutions to complicated computer science ideas.
Something I like is that I can create content containers without any data or titles when the content type has no fields. But once fields have been added I can see them in the content edit form and enter data. Containers are identified by unique ids rather than the database auto incremented integers. Id's are created at runtime and inserted to the database so it is not necessary to retrieve an id after. The id along with other meta is known beforehand. This also prevents collisions when writing to the database table and removes the need for table locks.
So CCK will have many of the developer features of Drupal. Just designed and coded differently without the fancy semantics and built in magic. Without the alphabet soup of design patterns and "standards" acronyms,"for the enterprise" posturing. Starting with:
Content Types
Drupal: Entities/node types/content types whatever always bugged me in that you could not create them easily it was always click, click, wait click decide click some more. Click eight times write four times and you have a content type. click four or five times more and you get field added.Wordpress: custom "post types" is never what you expect when using the GUI and adding fields is best done with code. Finding things later is always a pain and the sites themes always seems to self destruct when anything is customized using the post types. WP is just not built to handle this.
CCK: I made sure that there is a single click functionality for adding content types an adding fields to those types. If you want to add more detail later you can but eight clicks in CCK means you've created a content type and added seven fields to it. I made sure that CCK is built on content types and fields from the very beginning.
Drupal: delete the content type and the data is deleted. Delete the field and the data is deleted. This because the database schema in Drupal sucks. While the group at Drupal and Acquia have always had inventive programmers, the database is and always has been the weakest point of design. Maybe it's that no one interested in databases has ever worked on the project, for Acquia or their ideas get killed.
CCK: delete the content type and the data remains until garbage collected or recycled in to another content type. The same thing applies for content and fields. The CCK content system has Types, containers and fields that are loosely coupled and a I wrote the code to support the database schema rather than compromising both with complex solutions to complicated computer science ideas.
Something I like is that I can create content containers without any data or titles when the content type has no fields. But once fields have been added I can see them in the content edit form and enter data. Containers are identified by unique ids rather than the database auto incremented integers. Id's are created at runtime and inserted to the database so it is not necessary to retrieve an id after. The id along with other meta is known beforehand. This also prevents collisions when writing to the database table and removes the need for table locks.

Comments
Post a Comment