Smarty

I’ve been looking at Smarty and I’m hoping this isn’t a dumb question. To what extent do we expect users to employ Smarty?

Are add-on developers to be encouraged or discouraged when considering using Smarty .tpl files for snippet templates, for example? Or is Smarty to be reserved for the core?

What about using Smarty templates to solve problems in regular documents (assuming that even makes sense)?

Smarty is available as a "service" within the modX class. You could definitely use it on the front-end (I envision contexts that are nothing more than Smarty templates saved as Resources), but it’s primary purpose is for the "reference" manager implementation that ships with Revolution, or for adding custom manager pages to it. We can even produce Elements to use within Resources that are sourced as Smarty templates (vs. html chunks or PHP snippets) by simply adding a modSmartyElement class.

So originally it was intended for manager use, but I can see it being used as a general use service available to MODx as a whole.

What about using Smarty .tpl files instead of the existing .tpls in snippets like eForm, Ditto and Wayfinder? It seems to give more control over the display characteristics at run-time which some people might find useful.

Quote from: BobRay at Jul 31, 2008, 01:46 AM

What about using Smarty .tpl files instead of the existing .tpls in snippets like eForm, Ditto and Wayfinder? It seems to give more control over the display characteristics at run-time which some people might find useful.

Sure that’s possible, though it would be up to each snippet to initialize and utilize Smarty, which IMHO would not be especially efficient. At that point you basically would have two parsing engines working at the same time, and I don’t think that spells performance...you’d be better off creating a context of Smarty Resources that could be rendered with a custom modRequest derivative (a la modManagerRequest or modConnectorRequest) which would utilize Smarty instead of the MODx parser to process the .tpl just as the "reference" mgr context does.

How would that deal with snippet-defined placeholders?

Quote from: sottwell at Jul 31, 2008, 10:58 AM

How would that deal with snippet-defined placeholders?

It wouldn’t in my custom context approach; you would use Smarty markup to access Smarty variables that would need to be assigned by a script (or some kind of "controller" like those in the mgr), instead of placeholders, though turning placeholders into smarty variables would be trivial...

Or you could just return the Smarty-processed content back to the MODx parser with MODx tags in place and continue parsing, if you decided using both Smarty and MODx parsing together is what you wanted to do.

Quote from: sottwell at Jul 31, 2008, 10:58 AM

How would that deal with snippet-defined placeholders?

The way I thought of it, they would just become Smarty placeholders. Smarty calls them "variables" (which they are) and they are more powerful than placeholders in that they can include "modifiers" They’re set off by curly braces and the "modifier" is the part after the "|".




You can see more here: http://www.smarty.net/crashcourse.php

Ok, but where will they come from? In pure MODx, the snippet uses $modx->setPlaceholder(’name’, ’value’), and the parser does the replacement. How would Smarty get that value?

Quote from: sottwell at Jul 31, 2008, 03:44 PM

Ok, but where will they come from? In pure MODx, the snippet uses $modx->setPlaceholder(’name’, ’value’), and the parser does the replacement. How would Smarty get that value?

$smarty->assign(’name’, ’value’);

So the snippet has to be Smarty-aware, then.