Hard-coded content vs. content variables

I’ve been noticing some talk in the forums lately about wanting to hide built-in content in QuickEdit and I think they have a very good point. Many pages don’t need a longtitle, summary, menutitle or even a content field.

I really think the right solution is to turn all of these fields (and maybe more) into content variables that are installed by default. This would also give us a lot of advantages aside from lack of clutter in certain templates such as getting rid of the Rich Text option, being able to use richtext editors for other fields like description and summary, defaults, permissions, widgets, etc.

This would of course require a bit good bit of modification to the API and the manager but they should be mostly simple changes. First of all, I suppose we need to agree that this needs to be done. Secondly, we need to decide what version we want to shoot for.

What do you think?

Interesting thoughts, and kind of parallels some experimentation I’m doing in my development of my OO version of MODx. I considered making all of the metadata of a document an Element in my system, so it could behave in the manner of a TV (or chunk or script or whatever), but that means a lot of SQL overhead, with such complex normalization of the data model, especially considering every content element can be overridden by resource, can have multiple revisions, and can maintain multiple revisions in multiple languages. So I opted to stay away from that.

But then, after reviewing some other frameworks, I remembered things like the Dublin core, an open initiative to standardize document meta-data on the internet, and the metadata requirements for a workflow publishing system. Now I’m considering creating separate metadata structures in the data model to allow custom metadata sets (or taxonomies) that can be used for such things.

I’ll continue thinking on this...anyone else have some input?

I’m not sure how much this will impact performance but removing the content fields from the document table might not be a good idea.

It’s likely that future versions of the system will allow you to handle customized forms. This means that you will be able hide/show ContentFields based on the selected template as requested by a MODx user sometime last year.