template variables and placing content

Hi, I am evaluating using Modx. I’ve downloaded and played with the sample site. I am neither designer nor developer, but primarily a site admin, writer, and content editor. I have worked with databases, however, and some html and css. I understand the concepts behind web site design fairly well, just not all the details of the code -- which is why I want a cms. I’ve played with Drupal quite a bit, but it’s so complicated I can’t always understand what’s going on "under the hood" with all the admin and configuration (not to mention theming).

Modx looks good in the concept department. I understand how the pieces fit together. It seems very flexible, and I’m willing to learn, beg, or borrow for most of the actual code I need to make my sites. However, there are two things that are really still unclear to me, having to do with documents, templates, and template variables. And there are very practical implications.

1. Why doesn’t the tree in the Manager reflect template "instances" rather than content pieces ("documents")? Wouldn’t this correspond better to the actual pages one will have on a web site? Having a tree for all my content pieces is fine, but it’s not really a map of the web site, for the following reason.

What if I want to put two different pieces of content (i.e. documents) on the same web page? How would I put two different "content" tags on the same template? Shouldn’t I be able to flow more than one document onto a web page? (In looking at the fourth video tutorial for ExpressionEngine, you can specify a parameter for template tags to take the data from the specified weblog. You can mix and match content onto any given page.)

Nor is this a duplicate situation like a blog page needing to display many posts, where each document type is exactly the same as the one before. I assume the Ditto module is used for that task.

2. Why are template variables (used as custom content fields) attached to templates rather than documents (or, rather, to something like document or content "types")? I see this question has been asked before on the forums, but I don’t see an entirely satisfactory answer. A good database model would keep fields for a given content type (record) together for data entry, then pull on the data as needed for display. What if I want to display the same piece of content (with several fields) in two different ways, i.e. with two different templates? For example, what if I want both a web presentation and a printable version of the same document? Or, what if I want one subset of the content’s fields for one template, and another set for another one?

Thanks for explanation.

1. You don’t. Use TVs. You can embed more than one document’s content using a TV with @DOCUMENT binding. There are also a number of snippets to accomplish the same task in different manners; Ditto is one, as you have mentioned.

2. I’ve often wished documents were categorized, and TVs were attached to categories. But they work well as they are, it just takes a bit of getting used to them.

As far as different presentations of a document’s data, you can use as many templates as you like, or do some creative CSS with different stylesheets, like CSSZenGarden. Simply create a document and use snippets or TVs to pull the data you want from whatever documents you want. But in the vast majority of cases, the document => web page paradigm holds true.

There are a few discussions ongoing now about mobile presentation, involving using a plugin to switch templates as soon as the document request begins to be processed. Plugins are great for dynamically adding to or modifying the core processes without modifying the core code.

Thanks, I will have a look at TV bindings and snippets.

As to TVs and categories, I don’t know. Wordpress seems to use categories to subset or section out groups of blog posts for different treatment. It’s their way of getting around the one-blog (db table) limitation. EE has simply gone to using multiple "weblogs" (db tables), then defining the fields for each table, totally separate from display. But if you don’t want to have to think about and predefine data structures, it might not be a bad idea to tie them directly into on-site presentation (i.e. templates). I got to thinking about the problem of data entry last night, and it would seem it is just another web presentation task in the shape of providing an interactive form. Does Modx require data entry to go through the Manager or can you design forms (templates) to collect document data directly via the web site? Is there a preferred method or expectation here?

Yes, I can see the possibilities for using CSS to re-stylize a template, for example for web or print. Thanks for suggesting that. If necessary, though, how do you have "as many templates as you like" in Modx for a given document? Don’t you have to specify for each document which template it uses? When you talk about mobile presentation and switching templates, does that mean you could have a sort of a traffic cop template (with plug-ins), one attached to each document, which would then direct off to other templates for a variety of different actual displays? I could see that.

As to the majority of cases being document -> web page, I’m not so sure. In trying to figure out the core paradigms used by the various CMS’s out there (and what my own data looks like for my various projects), it seems to me there are least four different paradigms driving data and display. One is indeed the "article" idea, where each web page (minus headers, footers, sidebars) basically displays one long document. There is also the "list" idea, where a list of records (short or long, single field or multi-field) is presented, be they blog posts or teasers or titles or menu items. All the data is of the same type. You’re grabbing records from a single table (selected, sorted, with choice of fields to display). Third, there is the "database" idea, where the content of fields is presented in some more complex way, for example combining relational data. However it works, though, the data and relationships are well-defined. Finally, there is the "mashup" idea, where you just want to grab various kinds of content on an ad hoc basis, or through some kind of search, and throw it together onscreen, making it look nice and orderly (but where underlying data types vary widely and data interrelationships are neither neatly defined nor persistent).

Most CMS’s do articles and lists, along with headers, footers, and sidebars. Home pages often need custom coding. Wordpress does this for a single "blog," Joomla goes for articles, EE does multiple "blogs" and seems to be pushing towards a database paradigm (as is Drupal with CCK). If a truly database-y solution is required, you usually end up going with a totally custom design (not a CMS), using some kind of programmer/developer framework, or something more along the lines of Filemaker. Here the paradigm comes from client side apps, and the challenge is to make it web friendly. Mashups, on the other hand, seem to be the wave of the future, especially now that we have wildly powerful searching capability (Google turns up all kinds of stuff!) and tagging (coming out of the social computing craze -- again, turning up all kinds of stuff!). Drupal seems to be experimenting with mashups for Drupal 7.

How does Modx see itself?

As sottwell suggests, if you want to show more than one document on a web page, you can use template variables with the @DOCUMENT binding. You can also create a very simple snippet to pull them in. Note that the documents being pulled in don’t need to be published, which will automatically keep them out of menus and gives them a different look in the tree.
Of course you can also put the content in chunks and insert it into whatever pages you like with chunk tags. Or you can use Ditto or something similar to aggregate content from a number of pages into the current page. This all gives you tremendous flexibility in creating the site you want.

Having a one-to-one correspondence of tree items -> web pages might make MODx slightly easier to learn, but it would seriously compromise MODX’s power and flexibility.