Sankuru

What is a CCK (Content Creation Kit)?

The term CCK seems to originate from the Drupal world.

Drupal is another php-, LAMP-stack based CMS, competing with Joomla for the same client base. Drupal is very much the Java of the CMS world: always claiming to be better than the alternatives, but never actually proving it. I didn't say that Drupal is not a good CMS. I just say that the Drupal-touting crowd still hasn't substantiated its claims. It's a bit like with the Java crowd. If Java is so fantastic, then where are all the fantastic Java applications to prove it?

Yootheme seems to have a CCK now: Zoo. JoomSuite seems to have one too: Resources.

Zoo and Resources are hierarchical catalogs (directories) with configurable entry record fields.

Examples of CCK applications

A CCK toolkit allows you to create a product catalog -- for example -- and add custom fields to the product record, such as "Color", "Size", "Engine power", "Brand", "Energy consumption per mile", "Maximum speed", et cetera. This should allow you to list airplanes or cars in your product catalog, without the need to change the source code. Alleviating the need to change the source code is a Good Thing (tm).

You can use the same toolkit to create a categorized company directory. Categories could be: Retail Banks, Investment Banks, Payment Processors, Private Equity Managers, Hedge Funds, and so on. Next, you can add custom fields such as: "Yearly management fee per 1000 000 USD", "Minimum Capital Investment", "Commission on gains", "Commission on losses", and so on.

In fact, we already have a class leader in this category of Joomla extensions: Sobi2. Therefore, according to the Yootheme and JoomSuite definitions of CCK, Sobi2 is a CCK, and it happens to be the leader in their field.

Now, Sobi2 is actually a relatively okay piece of software. You can create custom fields, custom plugins to render specific modules in the catalog entry. It supports images, videos, and other multimedia data types.

What is EAV (Entity-Attribute-Value)

To cut a long story short, the EAV database architecture amounts to creating a database within a database, in order to gain tremendous flexibility. Instead of defining tables and fields, one defines a table with table definitions (Entities), a table with field definitions (Attributes), and a table with field values (Values). This gives you your own database inside a database.

Unfortunately, most of the enabling power afforded by relational database systems and the SQL language is lost, when using an EAV database architecture.

In the best, case EAV frameworks end up re-inventing an internal and incompatible, relational query engine, in order to re-gain these capabilities. In the worst case -- which is the case for Sobi2 and probably for JoomSuite and YooTheme too -- they simply leave you stranded with data that has become essentially unmanageable.

Without the core underlying data management mechanisms of a relational database engine, your database within a database, will inevitably turn into a data trashcan.

The catch with CCK is EAV

A great deal of the power of systems such as Joomla come from the SQL querying abilities afforded by the relational database sitting underneath it. However, CCK may and usually does rely heavily on an EAV database model for its data flexibility.

The EAV model may be built inside a relational database, but is itself not a relational database, with the typical regalia of a relational database; such as the ability to query it in SQL. Even though the use of SQL is still somehow possible in an EAV database, it is notoriously convoluted.

Regardless of all criticism possible on SQL and the relational database model, up till now, nobody has been able to phrase a viable alternative to the work of the illustrious Edgar Codd. It may indeed be possible to defeat Codd's 1970 seminal paper, "A Relational Model of Data for Large Shared Data Banks", but any such attempt requires first a fundamental breakthrough in the underlying mathematics and principles of set theory.

I do not say that this cannot be done. Even Isaac Newton was eventually defeated by the rigorous, and mathematically powered, assaults organized by Albert Einstein in his work on the General Theory of Relativity (GR). I am just saying that Sobi2, (and Yootheme, and JoomSuite for that matter) give the impression to be too lightweight to even contemplate a victory over Codd.

Magento and CCK

The Magento shopping cart, also heavily based on EAV, exposes the same problem. Let's support this with a few quotes:

magentosites.com
Developing for Magento "Nothing turns the easy into impossible like Magento" is an endearing tag line given to Magento by developers who've wasted hours trying to make even the simplest of changes to the code.

www.exploremagento.com: "Developing for Magento is often hard..."

This excess complexity, resulting from using an EAV database architecture, does have financial repercussions. Magento projects are expensive. Just read here why a Magento project is not suited for everybody's wallet.

Virtuemart and CCK

Virtuemart (VM) custom user fields are CCK-style, but do not rely on EAV. Therefore, they are very usable, and useful. I do recommend their use.

VM product types are also CCK-style, but unfortunately do rely on EAV. Therefore, I avoid VM product types like the plague. Instead, I just manually create additional fields in the product record.

The VM attribute system (simple, custom, advanced) is actually too underpowered to be considered CCK grade.

A good improvement to VM, would consist in rephrasing the VM product types and attributes to non-EAV CCK-style custom fields (and therefore make them work more like the VM custom user fields).

We do need CCK, but we do not need EAV

CCK is very much a standard extension mechanism that is applicable in any form in joomla. Therefore, it would be best organized as an underlying library. Forms that inherit from such standard CCK Form would know how to render CCK fields, how to store their data (and most ominously) know where to go for validation. 

A CCK Form would also have to register with some kind of CCK forms repository. A backend extension would be then able to add/modify/delete custom fields to the CCK forms and their underlying tables. This approach would not increase the complexity of customizing Joomla sites, because most of the complexity would be handled by the CCK library, while CCK form fields and CCK table fields would simply look like ordinary ones.

It would require additional intelligence in upgrading, but that is already the case for any software that has been customized. Therefore, such approach would not introduce any fundamentally new problems.

Is there a need for a generic extension that manages hierarchical categories of records?

There is definitely a need for managing hierarchical categories of records, that is, trees or taxonomies.

But then again, implementing a generic extension to do this, will invariably be associated with the need for serious configuration and customization work, in order to add the domain-specific concepts. In the end, a used-car catalog is about used cars, and not about dealing with every possible problem in managing taxonomies.

It is not even certain that the common part between applications of this kind, is really large. Even though I do like to see attempts at creating general solutions, I am skeptical concerning the usability of their practical results.

Avoiding to touch the standard source code, is not a goal in itself. Reducing the efforts needed to build  applications, is the real goal. In the end, no matter how well an application's extension mechanism has been designed, we eventually end up having to touch its standard source code anyway. EAV and other design anti-patterns will turn this eventuality into a nightmare.

Therefore, when you discover the presence of design anti-pattern in the source code for an application, I recommend not use it as a building brick for yours.

In that respect, the very absence of the application's source code, is undoubtedly the worst design anti-pattern possible.

Advice: What to do now

In my experience, a toolkit like Sobi2, initially cuts development time. However, when a sobi2-based application reaches a certain level of complexity, all gains will be reversed rapidly into steep losses, when the EAV monster inevitably rears its head, and starts hitting you mercilessly and with a vengeance.

There will always come a point when spending yet more resources and yet more money will not cut it any longer. The only solution will then be a complete rewrite of the application. Throw everything away and start again.

Therefore, I recommend against the current breed of CCK extensions. As mentioned above, the CCK problem must fundamentally be solved in a different way:

• Stay clear from EAV;
• Create an inheritable CCK List and CCK Form;
• Create an admin toolkit to configure additional fields in CCK lists, forms, and underlying tables.