Rethinking MODx

Quote from: OpenGeek at Nov 07, 2006, 12:14 PM

Here’s some glimpses at how I envision, and have implemented the simplification of terminology in my rewritten core. I’ve got it down to two basic concepts which I think would greatly simplify the learning curve of MODx...

:o

Bowing to the clarity and cleverness of it all... at loss for words here...
I *love* this project and where it’s headed

@lovingmodx - yeah.. sorry. I realised that after I posted, and edited my post accordingly. Guess I should have posted anew instead. You are entirely correct.
And guys, I wasn’t at all serious about ’x’!

Anyway. For those that are new to MODx and enjoying this thread, OpenGeek has been busy rethinking the MODx core for the past year or two. I believe he’s rethought (recoded) the whole thing several times. He’s largely working independently from the rest of the team, and key parts of this are new to us, which is why even 0.9.5 RC1 still has Snippets under Resources rather than starting to introduce new terminology like Elements. Somehow I often end up the lone voice of dissent amongst the praise, so I’m going to take this opportunity to agree that Resources/Elements broadly makes sense and all efforts made are commendable.

So. As Resource will have types (document, weblink), it would seem that the idea we previously called DocumentType must now be ResourceSubType, and although I have yet to fathom exactly how my outline fits with OpenGeek’s new elements it still seems vaguely doable. What do you think, Jason?

Also, Jason, can you confirm how modules fit into this? Currently, a module is a PHP page that is added to the Manager menu. Is that then an element in itself, or do modules need to be rewritten to fit a typical front-end Resource + Elements model?

Does this have any impact on the way snippets like Ditto list content based on a "tags" TV? Does a better method open up with this new routine?

What does this let us do that we can’t now do? (I’m sure there are an unlimited number of things, but some examples would be nice).

When you guys discuss about TERMINOLOGY, it remind me of DRUPAL notorious terminology. They use words like

node (instead of content)
taxanomy, vacabulary, terms (instead of categories and subcategories, or tags)

Also take a look at this from Google Trend, I compare the 5 PACKT CMS award nominees
http://www.google.com/trends?q=drupal%2C+joomla%2C+e107%2C+xoops%2C+plone&ctab=0&geo=all&date=all

Look at Joomla! It’s a new word that is around 1 year old only.

Here is another one comparing joomla with mambo
http://www.google.com/trends?q=joomla%2C+mambo&ctab=0&geo=all&date=all

Here is why Joomla sucks in my optinion (I spend a lot of time with Joomla before I find out MODx)
1. No build in Search Engine Friendly URL (SEF)
2. No build in Comment System!
3. Limited hierarchy, all are Section->Category
4. Poor documentation for developers
5. Hard to instead simple PHP code! Even an echo ’Hello Word!’; will require creating a module. zzz
6. Too many configurations options for each item (each menu, each content, each listing)
7. Joomla site are to fix to the pattern (you can recognize a site made by joomla the first second you see it, i.e. how they list pages, the pagination style, the FAQ and Recent News on the top...)

The only praise for them is that there are a lot of extensions and templates available (both free and paid). They also have a lot of active developers and contributors. Increasing popularity and user base. Base on their ’number of users’, I believe they will win the PACKT competition. *dissapointed*

Sorry to be off topic!

BTW, did you guys notice a few of the CMS release important BETA at the same time? MODx 0.9.5, Drupal 5 and Joomla 1.5!

"Resources" makes perfect sense for me and also the explanation/reference to the commonly known "URLs".
So, a (typed) resource is what provides any type of, yep, content. From a string to a webcam’s image-stream to whatever. And what will you need in addition to make a special site, or service or application out of those resources?
"Elements"? Hmm, I would say that "Managers" or "Controllers" are what’s needed. To aggregate, syndicate, layout all the resources’ outputs.

EDIT: For me this would be a perfect CMF approach: using controllers to create applications to generate, control, combine resources. (It’s a nested concept, of course: on the next higher level a controller’s result will appear as a resource asf.)

I think that the concept for resources and elements are very easy to understand and would be easy to wrap one’s head around. I personally, feel that components or constructors might be better but if we got 1.0 with elements I am sure I could get my head around it just fine.

This thread is still the best on the forum and is snowballing into a tremendous process.

Quote from: PaulGregory at Nov 07, 2006, 02:18 PM

Anyway. For those that are new to MODx and enjoying this thread, OpenGeek has been busy rethinking the MODx core for the past year or two. I believe he’s rethought (recoded) the whole thing several times. He’s largely working independently from the rest of the team, and key parts of this are new to us, which is why even 0.9.5 RC1 still has Snippets under Resources rather than starting to introduce new terminology like Elements.

I think this is the single biggest semantic gap for us to bridge between the MODx of today, and the one I’m describing. And though it is an important one, I think if this switch of meanings surrounding Resources is the biggest change in terminology, it won’t be that bad.

Quote from: PaulGregory at Nov 07, 2006, 02:18 PM

Somehow I often end up the lone voice of dissent amongst the praise, so I’m going to take this opportunity to agree that Resources/Elements broadly makes sense and all efforts made are commendable.

:o

Quote from: PaulGregory at Nov 07, 2006, 02:18 PM

So. As Resource will have types (document, weblink), it would seem that the idea we previously called DocumentType must now be ResourceSubType, and although I have yet to fathom exactly how my outline fits with OpenGeek’s new elements it still seems vaguely doable. What do you think, Jason?

Document Types (i.e. Document, Web Link) become Resource Class, because you implement a class to describe the behavior of that type of resource. If all you are doing though is creating Documents with different sets of meta data Elements attached, then you can attach those to the base element or any other Element common to your Resource Type, or even define specific Elements to apply to a Template only within a specific section (i.e. Context).

This is contrasted with content type handling, which might also be a little different than it is now. Currently, I have reimplemented this in the Elements layer. Let me explain. Each element defines what kind of content it returns, but Resources do not. This allows the use of a single resource to respond with various content types, say by attaching a snippet which dynamically sets the content type to be returned, which might be useful for some context-sensitive content delivery scenarios. But ultimately, the content type of a resource is defined by the content type of the base element attached to it. So if you attach an base element that returns HTML, your resource is an HTML content type.

Quote from: PaulGregory at Nov 07, 2006, 02:18 PM

Also, Jason, can you confirm how modules fit into this? Currently, a module is a PHP page that is added to the Manager menu. Is that then an element in itself, or do modules need to be rewritten to fit a typical front-end Resource + Elements model?

In my mind, no need for Modules at all. They are the same as script elements in this new architecture since Manager pages can be built in the same way as the front-end. So yes, they would likely need to be rewritten, but considering they become as easy to build and customize as the site itself and I think the required effort is worth it.

Quote from: PaulGregory at Nov 07, 2006, 02:18 PM

Does this have any impact on the way snippets like Ditto list content based on a "tags" TV? Does a better method open up with this new routine?

You add power in the fact that you can define hierarchical tag structures by relating elements together, and you can then do things like attach tags to Elements of a Resource, which brings the categorization capabilities to the same level as the reusable content Elements themselves. I think other improvements related to contexts and caching will have more impact on the performance and capabilities of snippets like Ditto and Wayfinder, which list resources in various ways.

Quote from: PaulGregory at Nov 07, 2006, 02:18 PM

What does this let us do that we can’t now do? (I’m sure there are an unlimited number of things, but some examples would be nice).

Some examples of what the new architecture allows, some practical, some more abstract:

* Define Elements representing Dublin Core Metadata attributes for all your Resources
* Treat the default Resource content as just another Element with default values and such.
* Create Resource classes that handle XML web service requests or Ajax requests specifically and manage those within MODx.
* Create Resource and/or Element classes that get their content from a file instead of the content database.
* Create a Script Element class extension that parses MODx tags in the PHP source before evaluation (dynamic PHP code, similar to dynamic CSS)
* Allow all MODx Resource and Element behavior to be overridden or extended without touching a single core file.
* Chain together a set of Elements that define workflow patterns and/or security permissions and attach them to a Resource or another Element.
* Chain together a set of Script elements that are conditionally performed based on the execution of it’s dependents.

I’ll come up with some more when I have a little more time.

Jason, that sounds like the next generation of MODx will offer the ultimate flexibility and endless possibilities!

If I understand the concept, than the following scenario will be possible with next generation MODx. I want to provide downloads attached to my articles:

- I design a download publication type (the resource), which base content is the file to be downloaded (the element).

- Then I add another elements to that download resource - description (small textarea), filename to be served as my downloads need i18n characters (text), version (text), file size (PHP), file last modification date (PHP), mime-type of the file (dropdown list).

- Next I bind the download resource type to my article resource type as one of its elements to allow editors to add and edit attachments and users to download them. My editors are able to add one or more download elements to the article resource.

- Finally I attach permissions elements to article and download resources and their combinations to decide which users are allowed to download attachments, which editors are allowed to edit articles, and which editors are allowed to edit (add, delete) attachments.

The article resource itself also has a set of elements including title, long title, description, keywords, alias, layout template etc.

Will it be able to work that way?

Edit: You posted a reply while I was writing my post. From what I read my example is a simple case compared to the possible uses you mentioned. Great!

When we need to insert PHP code, we need to create a snippet, even simple php code. Some CMS allows admin to enter PHP code directly into the content (drupal, websitebaker...) which is quite useful esp for PHP code that is only used on that page only. Current MODx require us to create a snippet for each page. If we have 10 pages that require PHP code, we will need to create 10 pages and 10 different snippets. And each snippets is only use once on the individual page itself.

Quote from: lovingmodx at Nov 07, 2006, 05:12 PM

When we need to insert PHP code, we need to create a snippet, even simple php code. Some CMS allows admin to enter PHP code directly into the content (drupal, websitebaker...) which is quite useful esp for PHP code that is only used on that page only. Current MODx require us to create a snippet for each page. If we have 10 pages that require PHP code, we will need to create 10 pages and 10 different snippets. And each snippets is only use once on the individual page itself.

Implement a TV and put your PHP code in an @EVAL and you can add custom PHP to each page quickly and easily.

Quote from: OpenGeek at Nov 07, 2006, 12:14 PM

Here’s some glimpses at how I envision, and have implemented the simplification of terminology in my rewritten core. I’ve got it down to two basic concepts which I think would greatly simplify the learning curve of MODx...

Resources.
Documents, web links, or any other request "controller" (from MVC terminology) is going to generically be called Resources, because these are essentially virtual web resources that are accessible by a URL, or Uniform Resource Locator. Resources are assigned a base content element (see below) and can return any type of valid web content. A resource can then be as simple as a page or as complex as an Ajax or XML web services response.

Elements.
The re-usable building blocks of every resource are templates, chunks, snippets, TVs, plugins, etc. All of these become a type of Element. This is any element that defines source content and is expected to return a result when processed, be it a logical result, or content. Everything from the default content, to custom metadata, to complex TV-like controls, to PHP scripts can be attached as a Base Content Element (i.e. current MODx template, except it can be any kind of Element, including a snippet or TV) to a Resource, added to a Resource via an explicit relationship (ResourceElements), or related to any other Element (this will allow the current TV relationship directly with templates, as well as allow dependencies between all the other types of elements). Finally, consider that we can then define a class of Element that can represent permissions and is responsible for deciding if the user has permission for a particular element (piece of content or logic/behavior)...

Let me stop there, and see what kind of response this gets. There are additional concepts to talk about in regards to Elements for defining input controls and output widgets like TV’s currently allow, but I’d like to focus on validating these basic concepts in the context of this discussion first, and appreciate any of your thoughts on this, before I continue...

RIGHT ON!!!
This is Totaly clear (to me... I think... or maybe I just want it to be soooo bad)! You have an element. An element can be placed anywhere in any document. Each element can have its own properties, behaviors (methods), etc... kind of like an object. When the document is parsed, the element will display it’s properties or execute its behaviors according to its definition, context and messages it’s passed. Obviously, an element can contain an element, can contain an element, etc. Is that the idea?
In my crude home brew system I used the element concept(very rough though). For example, I have a weather forecast element. You can put the element anywhere. If you call it one way you get a one-day forecast, call it another you get 6 days. The element itself spits out all the HTML, including the appropriate CSS class, to display the element. In something like MODx I’m guessing you could go several steps further by doing things like checking the width and height of the div or size of the cell that you had available and make adjustments accordingly.
I’m a MODx newB and my biggest stumbling block has been the lingo. Thins like "Template Variable" that is given a "Value" have completely thrown me for a loop!
I hope I’m not completely out in the weeds again,
joe