In demand

ad1

Tuesday, May 12, 2015

API-centric page and data separation for CCK

The Content Connection Kit architecture is such the  pages and data are separate. The developer or site owner can create  content  by  first   setting a  container and it's data as a visual page.  They may then delete the container and leave the data.  This means the data can be accessed via a web service query and presented as json or xml for consumption by others.  The same is true for the forms and fields. A field can set for a  content type for user input.  If the field is later deleted  the developer may leave the data in the system so any query calls to the services API's may access the data.

In other words data is parented to the visual presentation of pages and can be orphaned from it. The content is not contained or linked to a  field, only referenced and is not destroyed when a page presenter is removed.  Data is deleted explicitly not implicitly. This is what makes CCK different from a Content Management system. The architecture is API-centric working like a framework and not totally wrapped in visual entities.

Why Content "Connection" Kit and not "Construction"

Someone made the comment that CCK was a standard acronym for Content Construction Kit. I say this is an narrow, outdated and wrong way of thinking about todays web. Today it's not about building pages and constructing them with user content. Now it's all about the things that connect content like:


  • disconnected  data 
  • API's without presentation
  • web services

This is why I and many others have stopped using CMS's like Drupal  and  Wordpress because while they are great for collecting user content and presenting it as a web page they are terrible at connecting that content to internal and external systems that consume it.  Developers struggle to strip away the layers that are in the way of  modern usage with plug-ins and modules which works to some degree . But ultimately the architecture of the CMS  gets in the way. and  they become overwhelmed by performance issues. The complications and unwanted complexities of trying to decouple monolithic designs and  user automaticity support systems  lurk in the shadows. They wait for any business not matter how small to attempt to do something other than  manage the collection of user content and data.

This is way FHQK Universals  Content Connection Kit is  different from a CMS.  For those that don't know you could say that  it is a core build of  typical CMS ideas and the things I  like:

  • content types, 
  • content fields
  •  forms API
  •  menus 
  • taxonomy systems
  • MVC 
  • OOP Classes as plug-ins
  • built-in documentation system
  • Always on the latest version of PHP
  • PHP and CSS3 and HTML5 only no javascript, not even a bit.
  • Straight to the method design without abstraction or any of the acronyms like DI, ORM blah blah.

Only the tiniest amount of "magic" is used to tie the system together. There are no pages unless the content is connected together to present one. As a matter of  fact CCK works without any content what so ever. The system is not dependent on user input to work.  There's no list of end-user features. But the above list of developer and application builder features is growing.

It's a kit not a framework  micro or otherwise! CCK is not a pile of legos on the floor waiting to be put together as something useful.  CCK  is a  prefabricated architecture for building a web site or  application.

And as always CCK is not vaporware you can see the  implementation of the  ideas at the live development site  cck.fhqk.com

Print this!