Revo Template Var syntax (* or +)

Hi All,

I’ve installed the new Revo and am slowly digesting its differences from Evo.
I’ve been browsing the docs, and the forums, and looked at this post:

http://rtfm.modx.com/display/revolution20/Tag+Syntax

and saw that template vars were called with the * syntax, [[*tv_name]].
That worked in the body of a resource, but when I tried to use that syntax
in a chunk, it didn’t work. It took a lot of time and searching, but I finally
figured out that I had to use [[+tv_name]], which I didn’t really see documented anywhere.

I also saw that [[+name]] was the syntax for placeholders. And I saw that
[[*name]] was the syntax for resource fields, except in chunks.

I guess I’m asking for clarification on this, as well as suggesting that the tag doc get updated, because it was frustrating researching this .

And, am I correct that adding an exclamation after the initial two brackets [[! will make any of the tags uncached?

In Evo the second bracket was replaced, so I wanted to confirm that as well.

Thanks,

Peter Brown

Yes, exclamation point is uncached. Now you can call uncached chunks [[!$, snippets[[! and even placeholders [[!+.

You kind of answer some of your questions...

I also saw that [[+name]] was the syntax for placeholders. And I saw that
[[*name]] was the syntax for resource fields, except in chunks.

[[* for template variables and [[+ inside chunks and sometimes inside snippets like Ditto.
[[+ for placeholders

Thanks....

I hope the tag doc is updated.

Peter

I also saw that [[+name]] was the syntax for placeholders. And I saw that
[[*name]] was the syntax for resource fields, except in chunks.

[[*name]] is processed by the MODx parser, and refers to the value for ’this’ resource (the resource with the Ditto snippet call on it). [[+name]] is a placeholder, and will be parsed by the snippet (such as Wayfinder or Ditto), and refers to the value for the resource the snippet is working with as it loops through the resources it’s told to use. So if you were to use [[*name]] in a Ditto or Wayfinder tpl, it would be ignored by Ditto and processed by the MODx parser, and thus get the value for the resource the Ditto snippet is on, not the individual item resource Ditto is looping over and applying its tpl to.

For example, [[+id]] in its tpl will be processed by Ditto for each resource it’s looping over, displaying a different value for each item. But [[*id]] will get the same value each time, displaying the ID of the resource with the Ditto snippet call on it.

Dear Susan,

That makes a great deal of sense.

Was that in the docs somewhere, that I missed?
I much prefer to not bother anyone, and actually

rtfm

but I couldn’t find that point at all today.

Peter

As far as I know it isn’t; I explain it fairly often as I feel it’s best to understand why something works as it does. Actually, it’s really only simple logic... once you get firmly in mind that you are dealing with two different sets of resources - the resource being parsed to produce the page that will be viewed to which [[*name]] applies, and the resources the snippet is processing to make its aggregate list for display on the resource being processed where [[+name]] is a placeholder for that resource’s TV or resource variable values.

The tpls (frequently chunks, sometimes files or other methods of defining the tpl) use placeholders because the snippet has to get the TV or resource variable’s value for each resource it’s processing. While it could have been coded to use the regular [[*name]] syntax, taking it fresh each time from the resource it’s processing in the loop, then how would you ever get the value for the actual page being processed to be used? This would especially be important if your tpl contained a form and you needed to have the form’s action URL be generated from the main containing page’s ID.

Dear Susan,

I agree, it’s excellent logic.

But, since the syntax is arbitrary, created by the hard-working authors, it’s
helpful to have that syntax documented somewhere, just to save time.

Thanks for your very helpful answer!

Peter