Chunks are Templates...

So why do they exist? Why have that extra classification to slow down and confuse those of us new to modx?

Templates are used to layout your site, however chunks are used for things that may appear over multiple templates.

For example lets say you have 6 templates for different layouts but they all have the same footer, in this instance you would put the footer in a chunk and call it into all the templates. This way when you need to edit the footer all you actually edit is the chunk and it shows on all templates ( bit like a php include )

Maybe this will help illustrate my point: if I use my computer like a hammer, is it a computer or a hammer?

I don’t think the name of something should change based on how it is used.

Edit: Thanks for your input paulp. I don’t want to be a pain or anything, but simplicity is pretty important to me. I have no problem with supplementing a name with some sort of classification. Chunks could have been called "include templates". Expression Engine templates that are not web accessible and are meant for includes are still templates, they are just prefixed with a dot as a convention.

It’s just a matter of becoming more familiar with the terminology used in MODx. A template is an outline of an entire web page’s HTML elements, a skeleton to serve as a structure. A Lego base plate.

Chunks are smaller... well, chunks of HTML. Lego blocks. They can serve any number of purposes, from blocks of content, such as sidebar blocks and footers, to mini-templates for Wayfinder and Ditto output or customizable eForm and Jot forms. It is much more convenient to have sidebar blocks such as a search form and a login form in chunks, and include the chunk tags in the template as desired. Combined with template variables, they make it very simple to mix and match blocks of content on a page-by-page basis. They also help break out blocks of content from the main template, keeping the main template clean and structurally uncluttered with bits and pieces of content. You can see at a glance where everything is in the template.

And, as paulp mentioned, they are very convenient for parts of the site that are consistent across different template structures. For example, you may have three columns on the home page, two columns on most other pages, with a few pages having a single column. But all have the same masthead, main menu, and footer. Much simpler to have some way to have those blocks of content in one place, with the ability to include them in each template, than to have to deal with the same content in several different places.

It’s understandable that having several options for organizing a page’s structure and content can be confusing at first, but once mastered only the imagination is the limit to the ways it can be manipulated.

A five-pound sledge hammer is quite useful for splitting firewood, but a tack hammer is better for putting a backing on a picture frame. Both are hammers, but each has its purpose, and should not be confused.

Thanks for your reply sottwell.

Quote from: sottwell at Aug 27, 2010, 03:03 PM

It’s just a matter of becoming more familiar with the terminology used in MODx.

I know the terminology, I just find it superfluous.

A template is an outline of an entire web page’s HTML elements, a skeleton to serve as a structure. A Lego base plate.

Chunks are smaller... well, chunks of HTML. Lego blocks....

But they are both html and modx code. The entities themselves are no different. Their use is. That’s not justification for a completely different name imo. What if I wanted to make a template a chunk or vice-versa? It should be just a matter of removing/adding <html>, <head>, and <body> tags.

A five-pound sledge hammer is quite useful for splitting firewood, but a tack hammer is better for putting a backing on a picture frame. Both are hammers, but each has its purpose, and should not be confused.

And they are both called hammers. That is precisely my point.


Anyway, I’ll leave it there.

What if I wanted to make a template a chunk or vice-versa? It should be just a matter of removing/adding <html>, <head>, and <body> tags.

The point is that it’s not that simple. What would you call a small chunk of HTML that you wish to embed in your template, or use as a Ditto or Jot mini-template? And how would you indicate to MODx that the one should be inserted into the other at a specified location in the latter?

If you understand how the parser works, you’ll realize that they aren’t the same thing at all, and serve entirely different purposes and are handled entirely differently. To get the best out of MODx, it’s important to understand why its different elements exist and how they are used.

Good luck trying to split an oak log into firewood with a steel wedge and a tack hammer. I’ve found a 5-pound sledge hammer to be much more effective.

Quote from: sottwell at Aug 27, 2010, 03:55 PM

What would you call a small chunk of HTML that you wish to embed in your template, or use as a Ditto or Jot mini-template?

A template.

And how would you indicate to MODx that the one should be inserted into the other at a specified location in the latter?

The same way it is done presently.

That’s a really good point, rickj... when editing a page, you could specify a Chunk to use to format its output. For the purists, you could simply have a category of Chunks that were the main "templates". And then you could call them all templates instead of the somewhat weird name of "Chunk". I mean, what is this? The Goonies? (just kidding)

In Revo, I’m not sure how the objects look... but my guess is that both the modChunk and modTemplate objects extend a base class, so I bet it would be possible to merge the two. I really like that idea, actually. That would solve some of the problems I’ve had here: http://modxcms.com/forums/index.php/topic,53588.0.html

Let me talk about this from a different perspective. First, chunks and templates are stored in different tables in the DB. Templates are tied to specific resources *in the DB*, chunks are not tied to anything -- they are independent and there is no field in their table to tie them to any other object. A chunk can be used in a snippet parameter, a template can’t. A resource can have only one template, but it can contain many chunks. Templates can contain chunks and chunks can contain other chunks but chunks can’t contain templates and templates can’t contain templates. Template Variables are tied to specific templates in the DB but there is no way to tie them to a specific chunk.

Both templates and chunks can be used for "templating" in the general sense of the word, but as Susan says, templates can *only* be used that way (without bending MODx) and chunks can be used for lots of other things (including storing data and serving as parameter values in snippet tags -- neither of which have anything to do with "templating" in any normal sense of the word).

Generally, chunks that are being used by a snippet or plugin for templating, are called Tpl chunks, although some people erroneously refer to them as "templates" which adds to the confusion, IMO. Note that Tpl chunks in this case are being processed by the specific snippet or plugin code entered manually by the element’s developer, they are not being processed by the MODx parser itself, which processes actual templates automatically with no intervention on the part of the developer.

Some of this is for legacy reasons. It would certainly be possible to merge templates and chunks under a single name and make them interchangeable, but it would break *all* existing MODx sites and I don’t see it happening any time soon. Calling them by the same name at present, when they are different objects, stored in different tables in the DB -- with different structures, uses, and capabilities -- would be disastrous for all MODx users and especially hard on new users.

Additionnal example, you can use Chunk to make the xml markup for an RSS feed, which is not a template at all.
I’ve also use it to allow dynamic javascript to be generated. Examples are limitless.

They could change name, but they can’t be called template since they’re not.