Quote from: sottwell at Mar 28, 2007, 01:51 AM
My objection was the bloat it would add, loading up a whole ’nother library, but if we’re only using it for manager pages then it wouldn’t be so bad.
The integration is implemented as an optional service ($modx->services[’smarty’], also accessible as $modx->smarty), so Smarty is only loaded when needed, and the initial use case is definitely limited to manager page rendering. I’ve noticed no real difference in rendering times, and with the posts being handled by AJAX now, the number of page refreshes in the manager is greatly reduced as a result, making the experience at least seem much lighter and quicker. In addition, QuickEdit can now be refactored to take advantage of the new connectors to perform the same tasks from it’s own interface, as can any other management interface you want to build in the manager, front-end, or any context, Smarty or no Smarty.
Quote from: sottwell at Mar 28, 2007, 01:51 AM
Of course, there’s always just plain laziness... I’ve already gone to all the trouble of learning the existing MODx structure, now I’ll have to go learn how to use Smarty 
The good news here is that once you learn the new object-oriented MODx API, with any experience in PHP, the Smarty templates will look very familiar. Smarty exposes MODx objects directly, and so your learning-curve on this will likely be minimal. Consider the following block from one of the manager templates which illustrates how easy it is to work with the templates and the new API...
<th colspan="2">
<input name="locked" id="locked" type="checkbox" {if $chunk->locked EQ 1}checked="checked"{/if} />
<label for="locked">{$_lang.lock_htmlsnippet}</label>
<span class="comment">{$_lang.lock_htmlsnippet_msg}</span>
</th>
I think you’ll find that Smarty’s robust support for conditional logic and accessing PHP variables assigned to the template by the new controller files will make it infinitely easier to create custom manager interfaces, and could be used just as easily to do the same for front-end templates. In fact, I have plans to make both a modSmartyResource class (create documents that can be rendered using Smarty templates) and a modSmartyElement (embed Smarty templates within any other MODx Content Element, be it a template, a web resource’s content, template variable, snippet, chunk, etc.). But again, the key here these are all optional services and core extensions...