Framework vs CMS, Tattoo vs MODx : lets revive this and clarify !

I don’t mean to distract the team from the redesign, logo contest and 0.9.2 release but as Jason said in the "new logo coming" thread, we should have brought Jay (Smashingred) and Debbie (Mrs Communication) in the marketing team long ago... fresh blood, fresh views stirr new ideas and... revive old ones !

Debbies asked me to clarify the difference between MODx and Tattoo (she’s been reading the team forums and obviously the Tattoo threads are intriguing). That’s when I realized that we hadn’t talked about it for a while now.

Actually, funny thing is I had started thinking about Tattoo last week.

Since it has to do with my work on modxcms.fr, let me add some context. Most of you are probably unaware I have recently launched forums @modxcms.fr, which are not support forums (which will always remain here by the way) but "feedback" and business forums.

The goal of these forums is both invite the french community to express their wishes for modxcms.fr and for some of those who want to play a more active part, participate in the creative process. The other aspect of those boards is build a community of professionnals working with MODx (share good practices, experiences, start partnerships...). Last but not least, we have a "business, public sector and NPO" forum whose purpose is to answer questions any organization could have about MODx as a content management tool for their business, they can also publish bounty and inquiries.

Anyway (sorry for the digression), we’re just a week into this that we are already getting very interresting feeback from businesses (I have already posted a little about this). One of the questions asked was "What makes MODx a framework ?"

As I offered some explanation to business people I realized that it was very hard to explain that MODx was both a CMS and a CMF. Conceptually, it requires to jump into hoops to make it clear to businesses or end users. Of course I can explain (which I did) what is a framework, a CMS and a CMF.

I like wikipedia’s definition :

A content management framework is an application programming interface for creating a customized content management system.

Translate it to MODx’s case, it would mean MODx is a content management framework which is used to build the MODx content management system. Now how could that be confusing ? I remember Susan saying "MODx is a content management framework built on top of a CMS" and also with 0.9.7 "MODx will become a content management system built on top of a content management framework". This is so true...

I think we make our case marketing MODx harder by not giving a name to the framework upon which it’s built.

That’s when Tattoo clicked. Imagine communicating and marketing MODx this way : MODx is a highly flexible and customizable CMS built upon the modern and versatile Tattoo framework.

That would not only make it easier, but it would also mean that we could have (in due time) a line of Tattoo powered web applications : forum (I read somewhere that someone wanted to build a forum using MODx), wiki, gallery (MaxiGallery could almost qualify as a standalone application as it is !), or any content management application.

I confess that I just LOVED the tattoo logo and identity and the tagline is a killer : "Leave your mark".

I think it’s a great brand name and it could really make sense to revive this for the 0.9.7 launch. I am probably wrong, but I kind of think 0.9.7 is a turn point way beyond a 0.1 rev. I know the important thing is not rev number (which I don’t care that much about), but it makes some people hesitant to see that MODx is pre 1.0 (maybe they implicitely think in terms of linux rev numbering system).

I know this might seem to some like abstract semantics issues not worth wasting time but I think there is far more to it !
What do you think ?

I think you are 100% correct. MODx as it is is a very nice MODifiable eXtensible CMS, but it’s still at its core a CMS.

097, however, is another animal altogether. 097 itself is not the core. The core is the xPDO framework, and 097 is just a model that is built on the framework.

And that’s where I keep getting into trouble! I’m torn between just focusing on MODx on the xPDO framework, or learning the xPDO guts (as it were) and then seeing how MODx is built on that. Eventually I’ll understand both, but it will take me a lot longer. And then of course there’s the Smarty business since the MODx manager is built with that.

Quote from: sottwell at Feb 21, 2008, 03:40 AM

097, however, is another animal altogether. 097 itself is not the core. The core is the xPDO framework, and 097 is just a model that is built on the framework.

Ok now I am a bit confused... my understanding was xPDO was a "a light-weight ORB library that works on PHP 4 and 5 (....) It implements the very simple, but effective Active Record pattern for data access." (cf xpdo.org).

Now, I did my homework and check a definition for ActiveRecord :

Active record is an approach to accessing data in a database. A database table or view is wrapped into a class, thus an object instance is tied to a single row in the table. After creation of an object, a new row is added to the table upon save. Any object loaded gets its information from the database; when an object is updated, the corresponding row in the table is also updated. The wrapper class implements accessor methods or properties for each column in the table or view.

I can almost understand the concept , but does the framework upon which MODx 0.9.7 is built not also include the API, not "only" xPDO ?

Quote from: sottwell at Feb 21, 2008, 03:40 AM

And then of course there’s the Smarty business since the MODx manager is built with that.

I think the value of Smarty as a template engine when used with xPDO is explained here (at the end of the page "Hydrating object variables").
Don’t ask me what it means, though

Edit : Started reading http://www.xpdo.org/documentation/getting-started.html -> it’s really great

My point was that with MODx as it is, all of MODx is the whole thing, CMS, CMF and all.

But with 097, the MODx part is just one model that is being developed to work on the xPDO based framework. The framework itself (I realize I was being inaccurate by calling the whole framework "xPDO", the framework uses xPDO) can be used for whatever you like, it doesn’t have to have MODx at all.

For example, you can use this xPDO based framework to develop a forum model. It can be totally independent of MODx, MODx may not even exist in the application. Or, both MODx and the forum can be sharing framework units, such as the user management unit, and the forum could have access to specified documents in the MODx model so the forum could be a commenting system for the MODx documents. But they are still two different models, just sharing access to certain objects.

At least this is my rather vague understanding of it.

Interesting thoughts. Though the current plans call for Tattoo becoming a highly optimized, PHP 5.2.x+ only distribution with strong commercial support available there’s more to think about here. Thanks for bringing it up these ideas.

xPDO is the database access and manipulation and abstraction and ____ layer.

The framework is the collection of those DB-bits and logic tying them all together including the packaging mechanisms, access controls, etc.

The CMS is the collection of those things with the UI on top of it all to make it easily accessible and usable by normal humans who don’t think in bits and bytes as a first reaction.

Quote from: rthrash at Feb 21, 2008, 08:20 AM

Interesting thoughts. Though the current plans call for Tattoo becoming a highly optimized, PHP 5.2.x+ only distribution with strong commercial support available there’s more to think about here. Thanks for bringing it up these ideas.

Happy Tattoo is not under the carpet, and excited about a highly optimized 5.2+ distribution...

Quote from: rthrash

xPDO is the database access and manipulation and abstraction and ____ layer. The framework is the collection of those DB-bits and logic tying them all together including the packaging mechanisms, access controls, etc. The CMS is the collection of those things with the UI on top of it all to make it easily accessible and usable by normal humans who don’t think in bits and bytes as a first reaction.

Crystal clear, thanks !

*faints in confusion*...

Okay. So what is MODx? Why is it different and who needs to know what?

The thing is that most people don’t care, they are goal and task oriented and whatever application meets their want will fill that need. MODx meets many needs and wants for the Marketing Team the challenge is to provide the access for those specific levels of understanding. A business person doesn’t really need to know "how" MODx works but that it will work in the way they want and or better than they expect. A designer, developer and an end user all have differing goals and so the vectors of understanding for each group will inherently need to be different.

This is why comparisons between MODx and other CMS/Framworks fails as it tries to market the same message to all groups but that fails to provide solutions to any.

The new website will aid in doing this but we as a collective need to decide the best way to give each of the core groups the message they need.

When I first came to MODx as a designer I didn’t have the faintest clue what a framework was. At that time I had just gotten bored with WP and wanted something more flexible. I learned over time that conceptually that MODx was a framework and in context of MODX what that meant. It is not a framework in the same way that CakePHP is or RoR but it is a content delivery, management and control system with a user interface.

I will try to crystallize Ryan’s distinction here and possibly if other team members could comment explicitly on that it would be helpful. We don’t need to solve every semantic element but offer our consuming public meaning to help them solve their problems.

Cheers,

Jay

xPDO is an API for building an API into a specific model. The model represents the data structures and related logic that make up the functional part of an application. MODx 0.9.7 is a model in xPDO, and thus it is an API (replacing the one from 0.9.6 and before) into the MODx application.

In that sense, MODx is not a framework like CakePHP or RoR, but is essentially transforming into one for the next release. That’s the idea. Separate the application model from the interface and make the development framework part stronger without losing the great content management features already well-known in MODx.

To illustrate, when I rewrote this originally, it all worked with the existing manager; essentially there were two APIs working side-by-side to provide two different ways to access the same application, a new one that used the xPDO-based core alongside the old one that accessed the tables directly in MySQL.

So in a sense, you could call xPDO an object-oriented persistence framework (also called scaffolding), the new MODx core the CMF model developed with xPDO, and the new MODx manager interfaces a CMS application sitting on top of the CMF. And as Susan said, you could use xPDO by itself just as a persistence framework, or to build other models/applications, but MODx extends that core persistence framework to make it easy to create and manage content and components in a consistent manner within the application.

So I think I have it now. The trick here is to assign these descriptions as plain-English solutions to problems for the key targets of MODx.

The trick is to do as Steve Jobs did and explain that he has "10000 songs in his pocket." and not that he has a revolutionary storage system that can hold 1000s of MP3s, and other formats as well as does this that and the other.

I completely agree Jay. Trying to fit MODx into the typical moulds that are Cake/RoR-ish or Drupal/Joomla-ish just won’t work. David asked a question and I answered, but I don’t think that serves any particular user base or marketing effort particularly well. I certainly wouldn’t put it as content on a marketing site but if someone asks, which I presume to be the case (probably making me wrong yet again), then I’m gonna answer to the best of my ability.

I see two clearly appropriate users that we should target/profile in our efforts:

1) XHTML/CSS/(and possibly) JS web masters – Standardistas or SEO-mavens that actually care about having control and complete freedom to do things exactly how they want in the best way possible from and accessibility, search and flexibility perspective

2) Developers – those that are tired of hacking the core of other systems to get them to do what they want – and even more so those that are tired of building custom solutions from scratch every time (scalability and ubiquitous deployability to play a secondary role here)