Starting the Joomla CCK Conversation

Comment by Miguel Tuyaré on January 31, 2012 at 8:42am

Great work and very interesting. Jokte! is intended to cover several issues that you plant. We hope to accomplish with hard work, dedication and patience! (a lot of patience and time XD)

Comment by Joss Sanglier on January 31, 2012 at 11:23am

Thanks Miguel - feel free to translate it and put it round your people - if there is anything you can feed back into it, I will happily incorporate it either in the body or as an addendum ... or something!

Comment by Roger Matthews on February 11, 2012 at 12:41am

Wow, Josh, this is great work. I have struggled with exactly the same issues you are trying to solve. I am in the same  boat, a good user, but not a bit fiddler, so we have to become part of the fan club!  Please someone out there, listen to us.  This is great thinking, do NOT let it go to waste. Accomplishing what he describes would be a giant step from a darned good CMS to a truly great one!

Roger Matthews

Comment by Kareem Davies on February 15, 2012 at 11:13am

This sounds very, very well planned out even at this stage. Great Work

The problem really is how much of a rethink will it be from the extension developer's perspective?

Comment by Joss Sanglier on February 15, 2012 at 11:23am

Hi Kareem

This is something that has bothered me most of all. However, I went with the thought that the only way of NOT affecting the extension developer was to do nothing at all, which was a bit pointless.

Instead, what I have tried to do is come up with a route where the extension developer benefits in two ways:

1. When it comes to developing an extension, the built in JCF (Joomla Core Forms) should make at least part of the extension development easier - half the work is already done for you. In addition, if the com_content component is rebuilt to handle the display of any table rather than primarily the #_content table, a developer can again utilise those functions.

2. This also opens up the development of simpler extensions that are basically packs built around the new system. In theory, a competent admin can create lots of basic applications (even some more advanced applications) using the new core systems. However, many, many users out there are not up for that, and if they can down load and install premade functionality, then they will do so.

Obviously, the new system also open up a new thrid party development which is plug in functionality for the JCF system - that is an area that does not exist at all.

At the beginning of the process, a descision will have to be made:

a) This stays within the current Joomla environment in which case allowances have to be made for existing extensions (probably not a major problem, but it will mean a more weighty design).

b) It becomes a fork and you do not worry about existing extensions.

A hard decision! But this is why I have written this - to encourage people to work through that decision making process and come up with an answer.

Joss

Comment by Robert Vining on February 19, 2012 at 1:06am

You should really, really, really look at SobiPro. It already does about 75% of what you seek with this document. Output is XML, so data can be set to any view you create. It has just about any field type you can imagine, and it has a template system that is awesome. I even started a template club just for SobiPro templates. They install separately from the standard Joomla template and are independent of them. It also has 'Apps' that allow 3rd party devs to build upon SobiPro, and users can install Apps, like Review & Rating App, that allow you to customize each 'Section' of your site. Think of Sections as the types of content on your site.... a blog, a gallery, a directory... etc... It's young, but well built and growing quite quickly.

You should also have a look at the joomla mailing list for the Joomla Platform, as they are currently working on what they call a Unified Content Model (UCM) that will allow any content type to be built as you describe basically. They are talking about getting this implemented in 3.0 which is due in September.

https://groups.google.com/forum/?fromgroups#!topic/joomla-dev-platf...

Comment by Joss Sanglier on February 19, 2012 at 3:05am

Thanks Robert - SobiPro is one of many I have looked at. 

I will go look at the mailing list!

Comment by Gary Mort on March 23, 2012 at 1:57pm

To extend the discussion a bit:

First off the "existing" CCK" components for Joomla are not actually CCK components - this is where a lot of confusion in my opinion comes from.  They are instead alternative-content systems which include CCK options.  As such they often include a whole mess of additional and unneeded features alongside the CCK.  That is ok though since the current content component is not just a content component.  In addition to content, it also includes a voting component and a hit tracking component.

To boil things down a bit, CCK means having the option to:

1) Allow for input/storage of data fields for a document

2) Allow for using these additional fields to format/display the document

The need is for Joomla to support the "hooks" needed for CCK.

Joomla has, since V1, included the ability to for a CCK to exist by utilzing Mambot's.  Content generation plugins can locate triggers in a document or from the system and insert/change content based on those triggers.  Editor plugins can add additional input fields/functions to a content editing window to allow for the insertion of those triggers needed by the content generation plugins.

What has been missing, at a minimum, is a mechanisms for:

1) Fields - defining the name, what it looks like when displayed, how data is entered, and where data is stored.

2) Triggers - an officially documented mechanism for formatting triggers so that everyone can use the same format.

2.5 has come a long way in that it has the JForms and JFields classes which can, for the large part, be used to address the first item.  The problem I'm having is that their rather poorly documented and there needs to be many more documented, and preferably varying, methods of use.  I see a lot of 2.5 components today that don't use these new classes and instead are resorting to rolling their own solutions because the much more flexible JHTML classes are depreciated.

The second option really needs some community consensus.

Comment by Joss Sanglier on March 23, 2012 at 2:13pm

Ah, community consensus - that old utopian ideal!

One of the things I was trying to do subtly in my document is to move away from using the CCK term other than admitting that to a certain extent people know what that is meant to do and achieve.

The main bugbear for me, and something that probably is not going to be properly addressed, is data integrity.

Forget how I might decide data ought to be handled, a client, quite rightly, wants to be able to retrieve data in exactly the same fashion as he/she put it in. So, if they have a field called "name" they want to be able to go into the database and see a column called Name and have the "name" data in it - preferably unadultarated. (I know this runs into issues with HTML formatting in DB tables, but I have no idea how to solve that issue!)

What they don't want to see is a column called "all kinds of bits" and to find in it data from twenty fields with some proprietory deliminator shoved in there making it unreadable.

I know software designers like the idea of nailing a client down by making sure they have to use their programme to read the data, but more and more clients (especially government clients and larger companies) are realising that any data may need to be archived for years in digital format. Paper archives have the advantage that you don't need special programmes to read the data - digital data should try and move as near to that ideal as possible, allowing for the fact that there has to be some sort of system just to enable the storage - for instance MySQL. 

Probably too much of a Utopian ideal again - sorry, I have moments of being an idealist. Worse still, I think my clients are often right!

Comment by Gary Mort on March 23, 2012 at 10:20pm

Ah, the old "how to store the data" issue..

Personally, I liked how the CCK for Drupal 6 worked - basically you design a field[this field is "firstname" and is text, this field is "lastname" and is text, this field is "fullname" and is calculated by appending firstname space lastname and propercasing it]   Then for storing the data, for each article type you assigned fields to[think joomla categories], there would be a table named something like articletype_cck and it would have one column for each field to hold the data..appropriately named after the fieldname, ie column firstname has the firstname data... Plus some additional control fields.

I despise the "convert it to JSON/PHPserialize/someother weird format and stick it in a text blob.

Drupal 7 integrated much of the CCK functionality into the core code, calling it "fields" instead of cck.  Oddly enough they did something I both like and dislike.

I dislike their default data storage, it went the magentoo route where you have a table of field definitions, and then a table for all the field data in 3 columns.  Ie field definition table is "field id", "field name",,,other control data  and then there is one field data table for all fields defined as "row id", "article id", "field id", "field data" - so a left join of the article/node table to the field data table to the field definition table gives you all the field data - but it sure as heck isn't fun to browse.

What I liked though was that the field definition table had another config column called something like "datastore plugin" - where it specifies what function/plugin is used to retrieve that fields data.  So it was possible to create additional plugins for storing data in different ways and control which one to use at the field definition level.  So if you want a mostly flat table with one column per field you can do that.  If you want to store the data externally using a REST call to get/update data  -no problem.  

While last time I checked there weren't any other field data plugins...that just shows that most people don't care.  Wheras for those that do care, they can pay for developing it...

Comment

• ‹ Previous
• 1
• 2
• Next ›
• Page