Someone suggested that I post on here about a document I have written about "CCK" and the Joomla platform. This is not an extension discussion, but rather looks at the issue as being included in the core.
It is a detailed PDF that discusses the options, the reasoning, the issues that would need to be addressed, but it does not go as far as a full technical specification. The idea is that a technical brief would be drawn out from ideas generated by the discussion. I am not a coder, myself, so the document is written from the client/administrator point of view.
You can find more details on the All Together As A Whole site here:
That's an interesting topic and one I have a keen interest in as well. You might want to search this list for a big topic on what we call UCM (stands for Unified Content Model). It's an engine we are working on a eBay that would support CCK-like apps. I'd commend you to look at that in the view that it's a starting point for allowing CCK in any Joomla Platform Application (don't limit yourself to thinking just within the walls of the CMS).
So, in terms of this list, this is where we'd discuss the API side of things. Actually building the CCK interface would probably be something for the General or CMS list unless you want to do it as a stand-alone proof-of-concept application, in which case, we can probably help you out here. There are a few of us working on a refactor of the MVC pattern, and I think that will be helpful for you as well.
In the PDF I thought your closing political comments, in principle, were on the money :) It was great to see the amount of effort and thought you put into the document as a whole. But, as I said, also think about CCK in terms of applications on devices (of which a browser on a PC/whatever is just one), rather than something that goes into the Joomla CMS. It's quite ok for an application to have a hard-coded CCK, while other might allow for flexibility. The key is having an engine that supports however the developer wants to build the application.
Regards, Andrew Eddie
On 19 February 2012 19:17, Jsanglier <joss.sangl...@googlemail.com> wrote:
> Someone suggested that I post on here about a document I have written about "CCK" and the Joomla platform. This is not an extension discussion, but rather looks at the issue as being included in the core.
> It is a detailed PDF that discusses the options, the reasoning, the issues that would need to be addressed, but it does not go as far as a full technical specification. The idea is that a technical brief would be drawn out from ideas generated by the discussion. I am not a coder, myself, so the document is written from the client/administrator point of view.
> You can find more details on the All Together As A Whole site here:
Yes. I saw the UCM thread, but didn't want to just land in the middle of an already developed conversation.
You are quite right about not being limited within the walls of a CMS.
One of the arguments that kicks around is should the term CCK be used at all.
I sometimes wonder whether even the term CMS is used correctly. I cant remember if I put it in the document, but Joomla and many other "CMS" systems to me are really AMS - Article Management Systems.
Adding the versatility of a system that allows ANY sort of content to be managed, the only limitation being the imagination of user/client/developer, is when a program possibly deserves to be called a CMS. Mind you, that will probably get me shot!
Heh, I think CMS and CCK will do for now. The way I look at it is you'd install a CCK in the Joomla CMS, but it would run off the UCM package in the Platform (that would be my hope anyway).
The reality is though, that the CCK becomes the *only* content management system within the Joomla CMS in the long term, and I'm not sure if people have really grasped the implications of that. There would still be places for Zoo, JomSocial, K2, DOCMan and so on, but what they should become are different ways people can interface with the SAME content via a common content API (it's not Joomla articles, and Mosets directory entries and K2 articles, it's all the same content), or different toolkits with which you can build custom content (although, to be brutally honest, a lot of them become redundant when this is all said and done). It's going to be a very different world and a real game changer, as I think you've already mentioned. Conversely, it will cause a boom in the site builder side of things and the template companies should be thinking about this as well because it will suddenly create a new niche for them (and probably some headaches as well).
We'll just have to see what happens :)
Regards, Andrew Eddie
On 20 February 2012 09:33, Jsanglier <joss.sangl...@googlemail.com> wrote:
> Yes. I saw the UCM thread, but didn't want to just land in the middle of an > already developed conversation.
> You are quite right about not being limited within the walls of a CMS.
> One of the arguments that kicks around is should the term CCK be used at > all.
> I sometimes wonder whether even the term CMS is used correctly. I cant > remember if I put it in the document, but Joomla and many other "CMS" > systems to me are really AMS - Article Management Systems.
> Adding the versatility of a system that allows ANY sort of content to be > managed, the only limitation being the imagination of user/client/developer, > is when a program possibly deserves to be called a CMS. Mind you, that will > probably get me shot!
One of the reasons I have slight problems with the CCK term is that it implies something that is a tool in addition to the core.
The way I look at it in my system is that the core supplies the two sets of functionality, a form management/creation system and a templating system, that then allows CCK style functionality.
Once the forms and template system exist in such a way that they are easily available, both as a wizard guided system and as an API, then that functionality is available for any third party developers in any direction that they choose. They can create any number of tables of data, access them in any way that suits their purpose, but because it uses core functionality rather than having to reinvent the wheel, there is structural conformity throughout.
One thing I sneaked into my document which, much to my surprise has not been picked up by anyone so far, is my stipulation about data integrity.
I have this rather idealistic notion that a client's data should belong to them rather than become wedded to a proprietary system. Data should always be portable and therefore should be kept as clean as possible and not peppered with additional markup, for instance using separators to create arrays rather than putting information in a properly constructed table. Now, I know that there is a limit to this trick, but I do believe that as much as possible a client should be able to export data cleanly from any table (even if the original soft ware that put it in there is unavailable) and import it into another, unrelated system. It is the cynic in me that thinks that there are always going to be competing systems and the responsible supplier should not involve their client's data in the argument.
I need to make time to go through UCM stuff - it seems to be getting bigger faster than I am finding time to look at it. Is there an overview (non technical) somewhere I can look at to get at the philosophy and design parameters?
Drill into the /docs/ folder to find information about the classes. The main place to look is the content package. Remember though it's 1.0 stuff (maybe only 0.8 or 0.9). The next iteration will change things a bit by adding a data mapper pattern between the value objects and the data source, which is quite cool (and lightens up the content package significantly). Sam Moffatt will also be talking about this in Bangkok so hopefully they are videoing his sessions.
Regards, Andrew Eddie
On 21 February 2012 10:46, Jsanglier <joss.sangl...@googlemail.com> wrote:
> One of the reasons I have slight problems with the CCK term is that it > implies something that is a tool in addition to the core.
> The way I look at it in my system is that the core supplies the two sets of > functionality, a form management/creation system and a templating system, > that then allows CCK style functionality.
> Once the forms and template system exist in such a way that they are easily > available, both as a wizard guided system and as an API, then that > functionality is available for any third party developers in any direction > that they choose. They can create any number of tables of data, access them > in any way that suits their purpose, but because it uses core functionality > rather than having to reinvent the wheel, there is structural conformity > throughout.
> One thing I sneaked into my document which, much to my surprise has not been > picked up by anyone so far, is my stipulation about data integrity.
> I have this rather idealistic notion that a client's data should belong to > them rather than become wedded to a proprietary system. Data should always > be portable and therefore should be kept as clean as possible and not > peppered with additional markup, for instance using separators to create > arrays rather than putting information in a properly constructed table. Now, > I know that there is a limit to this trick, but I do believe that as much as > possible a client should be able to export data cleanly from any table (even > if the original soft ware that put it in there is unavailable) and import it > into another, unrelated system. It is the cynic in me that thinks that there > are always going to be competing systems and the responsible supplier should > not involve their client's data in the argument.
> I need to make time to go through UCM stuff - it seems to be getting bigger > faster than I am finding time to look at it. Is there an overview (non > technical) somewhere I can look at to get at the philosophy and > design parameters?
> Drill into the /docs/ folder to find information about the classes. > The main place to look is the content package. Remember though it's > 1.0 stuff (maybe only 0.8 or 0.9). The next iteration will change > things a bit by adding a data mapper pattern between the value objects > and the data source, which is quite cool (and lightens up the content > package significantly). Sam Moffatt will also be talking about this > in Bangkok so hopefully they are videoing his sessions.
> Regards, > Andrew Eddie
> On 21 February 2012 10:46, Jsanglier<joss.sangl...@googlemail.com> wrote: >> It could be even more fundemental.
>> One of the reasons I have slight problems with the CCK term is that it >> implies something that is a tool in addition to the core.
>> The way I look at it in my system is that the core supplies the two sets of >> functionality, a form management/creation system and a templating system, >> that then allows CCK style functionality.
>> Once the forms and template system exist in such a way that they are easily >> available, both as a wizard guided system and as an API, then that >> functionality is available for any third party developers in any direction >> that they choose. They can create any number of tables of data, access them >> in any way that suits their purpose, but because it uses core functionality >> rather than having to reinvent the wheel, there is structural conformity >> throughout.
>> One thing I sneaked into my document which, much to my surprise has not been >> picked up by anyone so far, is my stipulation about data integrity.
>> I have this rather idealistic notion that a client's data should belong to >> them rather than become wedded to a proprietary system. Data should always >> be portable and therefore should be kept as clean as possible and not >> peppered with additional markup, for instance using separators to create >> arrays rather than putting information in a properly constructed table. Now, >> I know that there is a limit to this trick, but I do believe that as much as >> possible a client should be able to export data cleanly from any table (even >> if the original soft ware that put it in there is unavailable) and import it >> into another, unrelated system. It is the cynic in me that thinks that there >> are always going to be competing systems and the responsible supplier should >> not involve their client's data in the argument.
>> I need to make time to go through UCM stuff - it seems to be getting bigger >> faster than I am finding time to look at it. Is there an overview (non >> technical) somewhere I can look at to get at the philosophy and >> design parameters?
