Rethinking MODx

Quote from: PaulGregory at Nov 07, 2006, 10:49 AM

To return to the "meta template" stuff: I know it’s just labels, but I’d rather documents were divided into DocumentTypes rather than PageTypes, as the document may not be a page, as has been pointed out in this thread.

DocumentType is nice, but just as everything is not a page, everything is not a document...
My initial problem about ContentType is the potential confusion with content-type (as in text/html, text/css...etc).

Quote from: PaulGregory

If we treat each and every variable on the Edit Document screen as a Document Variable, including Template, including whether it is Rich Text or not, including the content type and content itself, as well as any "Template Variables", then the next step leaps out.
Each DocumentType should be able to set the default values of all these variables - including Template.
This would override the variable’s own default value.

Now we’re talking !
That would be just plain awesome

Quote from: PaulGregory

This would associate the DocumentType with the template as David (and others) would like, but still provides room for over-riding it on a per-document basis without losing a load of variables. But David’s users could still accidentally change the template.

Unless they are not allowed to (permission-wise)...
In fact I have always been a little weary of having end users changing templates at all.

I have to allow it because I use TVs a lot, and template change is required to load the proper content fields for a document, but I am 100% for the idea of having a DocumentType (or whatever we call it) and having end users change that and only that.

It doesn’t mean MODx had to provide an automatic way of assigning template to DocumentTypes (I talked about the InheritTemplate plugin, I imagine another could be created to do just that).

Quote from: PaulGregory

So. Imagine next that as well as being able to set the default value, you can set whether these are editable...

Now here is another cool idea Paul, I love it !
And I love the concept behind it all. It articulates well, and it’s very MODx-ish.

Very probably Jason already has answers (with the 1.0 codebase) on several key items there for us...

Quote from: PaulGregory

Ping! Suddenly you are able to hide much of the complexity of the editor from other users.. suddenly it’s much easier for people to use. If they’re adding news pages that will be listed via Ditto, they just don’t need to see all the Uses template, Menu title, Menu index, Show in menu, Document parent stuff. You could go further and decide what user groups / level of access can change some of the variables, and Document Type is a sensible thing to connect to security. I also think that nested DocumentTypes will be beneficial - I can think of times when inheriting values from another DocumentType would be useful.

Woosh now I am all excited about where this is all going, I am bookmarking your post here

Quote from: PaulGregory

Now, how much of all this is the MODx 1.0 way??

My thoughts exactly...

This is where I think some form of master/nested template system could be powerful, especially if you could set an inherit/no inherit function, along with editing permissions.

Depending on the situation then you could remove the ability to select templates based on pre-setting the nested templates and inheirtability, then any page created within that section/folder/whatever, will provide the user with the appropriate nested template, in this case, perhaps your specific TVs for that section, or to take the book example here, the specific TVs for the book data, where creating a new page under the audio section, will automatically be pre-set with the nested template that has the TVs setup specifically for that kind of content.

I’d also be careful with the phrase DocumentType as people may make the association to DocType. No matter what, there will probably always be some kind of ambiguity or possible confusion with any term chosen.

@David: But we already call the damn things documents so at least we’re consistent! Better than introducing a second word (Page) to the mix.
@Identity: Yes, it’s close to Doctype. Ok, how about just "Type" ?

edit: OR.. because documents could be anything, we call them ’x’, and from there get xType and xVariables (or XVs) ? ? ?

@lovingmodx: You posted seconds after me, looks like we’re thinking the same way re enable/disable certain fields. If admins can set Not Viewable, Not Editable at the Variable level then we can have all that. And I get the feeling that we’re not the only ones thinking this way.

Oh, and Future Is Now:
Quote from: lovingmodx at Nov 07, 2006, 10:50 AM

If we click a document on the left pane, the page info is shown on the right pane. Well most of the time we click on it because we want to edit it, so why not have an options to allow user to choose what they want to do when we click on the tree node (the default action)? User can choose to display the page info (like now), or straight away to the edit page...

Er, so you’d like to be able to quickly go to Edit, or quickly go to Publish?

In the tree, try left-clicking on the icon, or right-clicking on the document name.

Edit2: Actually, re-reading your full thing, both the ideas you state (choose what default action is; have Save & Publish button) are valid in addition to the context menu, so I may be wrong to assume you’re unaware of it.

Quote from: PaulGregory at Nov 07, 2006, 11:26 AM

@David: But we already call the damn things documents so at least we’re consistent! Better than introducing a second word (Page) to the mix.

I have never proposed nor endorsed PageType just questionned ContentType as a "confuser".
I have nothing against DocumentType, I merely stated that not everything will be a document per say (link, file, whatever...) but you’re right we’re talking MODx documents I kind of (strangely) lost sight of that. For reference, I agree with your everyword on that post

Er, so you’d like to be able to quickly go to Edit, or quickly go to Publish?

1) Make sure you have a spare pair of pants handy.
2) In the tree, try left-clicking on the icon, or right-clicking on the document name.

I mean Edit when clicking on a tree node. Because I never bother about the page info (we can see those in the edit page as well). If we need to edit document now, we need 2 clicks, either left-click directly on the _small icon on the left and select edit. Or right click on the link and select edit. But what I do is right click on the link and select edit from the tab on the right pane. I am referring to the flow, some users might enjot just one click to edit and forever dump the info page.

The ’publish’ button that I refer here has nothing to do with the tree node or editing. I am refering to the situation when we are creating a new document. The current flow would be write the document, swicth to the ’Page Settings’ tab, check ’Published’, and click the save button. If there is a publish button just beside the save button for new documents, users don’t need to switch to ’page settings’ and check ’published?’ then only ’Save’. And my guess if when most people create a new document, they will forget to do the publish step and will need to come back to edit and check the ’published?’ again and re-save.

Quote from: PaulGregory at Nov 07, 2006, 11:26 AM

OR.. because documents could be anything, we call them ’x’, and from there get xType and xVariables (or XVs) ? ? ?

So that’s what the "x" in MODx stands for... anything... feeling like I’m back in high school algebra

The x stand for extensible if I am not mistaken. MOD is, I think, for modular. Thus MODx, modular and extensible system

Let’s not get into esoteric naming there, and stick to Jeff Veen’s "Please just use simple words to describe the things your system does"

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...

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.
[..]

Elements.
[..]

You seem to be pretty right with that, the first time I came to the MODx admin panel I didn’t quite figure out why the snippets were under ’Resources’ instead of ’Modules’. Though I think the name ’Elements’ might sound a bit too less of a CMS term, although it does show what it stands for pretty well, I guess it’s just the fact that it’s a totally ’new’ term (Instead of the overused things as ’extensions’, ’plugins’, ’blocks’ etc.)

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.
[..]

Elements.
[..]

Right on... right on.... right on... right on... Oh and in case i missed it, Hell yeah!
Little known fact, pirates like things when they just make sense.
I like this!

-sD-