MODX Staff
MODX Staff
I agree, the long forms should be used when practical, and short forms when space or brevity is an issue.
What do you think of changing the Manager menu labels to Web Resources and Content Elements?
MODX Staff
How about: Content Elements are reusable, modular pieces of source content that are processed to produce output or a result of some kind.
I’ve been struggling to come up with a definition of Content Elements that will make sense to a non-coder and will include Plugins. The closest I’ve come is "stuff that shows up in the Elements Tree" which isn’t really a definition.
They fit the definition above perfectly. The content in content elements refers to the source content which is processed to produce some kind of end result, whatever that may be. And each element class can define exactly how the source content will be processed.
Plugins are an anomaly because, unlike most other Content Elements, they have no Tags, don’t necessarily show up on Web pages, and don’t even necessarily have anything to do with page content.
MODX Staff
TVs are a powerful method of inserting blocks of content specific to the page being displayed. They take two basic forms:
1. TVs can display basic document attributes, which are found in the MODx database in the table (PREFIX)site_content table in the MODx database where (PREFIX) is your table prefix.
These are the most commonly used document attributes:
[*pagetitle*] - the title of the document
[*longtitle*] - the long title of the document
[*introtext*] - the summary of the document
[*content*] - the content of the document
[*id*] - the unique numeric ID of the document
MODX Staff
Well, I didn’t write that document, nor did I chose the terms there, but the [[*modFieldTag/modTemplateVar]] tag format is shared by those two classes and processed differently based on whether the tag name is identifying a simple field value from the site_content table or a modTemplateVar instance added to the Resource that is constructed from the site_content table row. I can tell you that a property, an attribute, a field, or variable are all common terms for the same thing. I think we’re getting lost in a sea of similar semantics and getting a bit nitpicky here. I’m all for clarity and consistency, but people used to using these terms in the development world simply know they are interchangeable. The class is modFieldTag, so I would say let’s call them Resource Fields if they are on the table and Template Variables when they are, well, Template Variables. The Template Variables, which become virtual fields on the Resource (i.e. via the legacy documentObject), are essentially just "fancy" "custom" Fields/Attributes/Variables that are related to the Resource object.
That sounds really cool, but right now, I’m more concerned with coming up with a taxonomy that can be understood by regular humans (including me). I’m afraid your post got me further away rather than closer.
This is from the MODx Tags page of modxcms.com:
TVs are a powerful method of inserting blocks of content specific to the page being displayed. They take two basic forms:
1. TVs can display basic document attributes, which are found in the MODx database in the table (PREFIX)site_content table in the MODx database where (PREFIX) is your table prefix.
These are the most commonly used document attributes:
[*pagetitle*] - the title of the document
[*longtitle*] - the long title of the document
[*introtext*] - the summary of the document
[*content*] - the content of the document
[*id*] - the unique numeric ID of the document
This appears to say that all the fields in the site_content table are TVs and that TVs=Document Attributes (those *are* TV tags, after all). It also implies that the things created by users are either just more TVs or Custom TVs. We can certainly change that usage, but it may confuse people.
You could say that the TVs are the tags and that they represent, show, or are replaced by, Resource Fields, but clearly when you add a TV in the document create/edit panel, you’re creating an object, not a tag.
So what do I do? I can’t wait for 2.1, I don’t want to use language that will be obsolete in 2.1, and I have to make sense and be consistent with the other docs.
Yes, they will still be accessible via the Content Tags identified by the * token. The difference will be that the content oriented fields that currently exist on the site_content table will simply be moved to become Content Elements that are directly related to a Resource (rather than through a Template). I’ll discuss this more when we get there, otherwise, it’s going to confuse you more, as this will make it possible to attach any kind of Element to the Resource to return the output, and will involve the removal of Template Variables as a distinct Element class (likely to become simply modContentElement or maybe just modElement, i.e. the base class providing the simplest functionality). Regardless, that’s to be messed with after we successfully launch 2.0.
In 2.1, will menuindex and content_dispo be displayable via TV tags? Will TV tags be renamed? Will the term TV still exist? And what’s the target date (roughly) for 2.1?
I would say let’s call them Resource Fields if they are on the table and Template Variables when they are, well, Template Variables. The Template Variables, which become virtual fields on the Resource (i.e. via the legacy documentObject), are essentially just "fancy" "custom" Fields/Attributes/Variables that are related to the Resource object.
MODX Staff
Sounds perfect, though I want to phase out use of the term documentObject as well, of course. It’s synonymous with Resource now and was really inaccurate, cause it wasn’t an object at all, but an array.
What about this scheme, which kind of bridges between past and future:
Resource Fields (AKA Resource attributes) - All the fields in the site_content table. Some of the which are on the create/edit resource screen and some of which are available through the documentObject.
Template Variables - Custom Resource Fields added by the user.
[[*name ]] - Content Tags, which can be used to display both Resource Fields and Template Variables (and, in the future will display Content Elements if I’m understanding you).
It seems consistent and workable to me, it cuts down the number of terms people have to learn, and it starts the process of getting rid of Template Variables (I never liked the term TV Tags; I think it’s caused a lot of confusion).
Best of all, it’s completely logical from the non-coder’s viewpoint. I.e., we put the most commonly used Resource Fields on the create/edit screen, but you can get the rest if you need them (via the documentObject), and if you need something beyond that, you can create a Template Variable. All of them are Content and all or them can be displayed with Content Tags.
In 2.0, $modx->documentObject is basically just a reference to $modx->resource->_fields array (which contains all of the columns of the site_content table) with the legacy tv array value structures added in. Instead of using $modx->documentObject, which is deprecated, use $modx->resource. It’s an object and a lot more flexible to work with, e.g.:<?php
// access some resource fields directly as object vars
$id = $modx->resource->id;
// access the resource fields with the get() function
$alias = $modx->resource->get('alias');
$createdOn = $modx->resource->get('createdon', '%Y-%m-%d');
// access multiple resource fields with the get function
$someAttributes = $modx->resource->get(array('pagetitle', 'longtitle', 'introtext'));
// access all the resource fields with the toArray() function
$allAttributes = $modx->resource->toArray();
?>