Smarty

[jablko]

http://cgi.sfu.ca/~jdbates/tmp/smarty/200606240/patch

1) This patch adds an {append} custom compiler function, symmetical with the {assign} custom compiler function

2) Adds an 'append' argument to {capture}: {capture append="foo"}

3) Adds support for structured variables to $smarty->assign & $smarty->append, enabling:


{capture append="ItemReorder.update"}
YAHOO.util.Dom.get("{"targetSelect"|elementId}").innerHTML = html;
{/capture}

[...]

<script>
// <![CDATA[

{* Template's client-side variables & functions *}
var ItemReorder = {ldelim}

{* Update template's dynamic elements *}
update: function(ItemReorder) {ldelim}
{$ItemReorder.update}
{rdelim}
{rdelim};

// ]]>
</script>


My Summer of Code project is adding an Ajax interface to Gallery's ItemAdmin system - http://code.google.com/soc/gallery/appinfo.html?csaid=86AF53A624C64E81

So far I have used a {g->callbackContent} block plugin to define Ajax response bodies in the templates they update. Faced with adding more features to this plugin, however, I switched to combining generic Smarty tags:


{* Ajax callback output *}
{if GalleryUtilities::isCallback()}
{capture append="smarty.output"}
{if empty($status.saved)}
YAHOO.util.Dom.get("{"status"|elementId}").style.display = "none";
{else}
YAHOO.util.Dom.get("{"status"|elementId}").style.display = "";
{/if}
{/capture}
{/if}


To define callback response bodies with generic Smarty tags, it is important 1) to easily append block contents to variables, and 2) to append to structured variables like "smarty.output"

Appending to structured variables is important because Gallery's templates are nested, & at each level Gallery pushes a $smarty->_tpl_vars context onto the stack. Consequently it's not possible for a template to return block contents to the Gallery app using: {capture append="foo"}

Many thanks - Jack

[boots]

Hi and thanks for submitting your patch.

I'll have to review this. To date, the template language has been kept from growing to the point where it is specifying and creating var structure. When needed, these are provided as 3rd party addons/plugins.

As a side note, why is capture used so aggressively and can you comment on some of the changes you are suggesting? I managed to create a plugin stack hierarchy without modifying any part of Smarty: http://www.phpinsider.com/smarty-forum/viewtopic.php?t=4125 ...which is not even a great implementation of the idea but demonstrates it is possible.

At any rate, I notice that your patch also contains non related formatting changes (such as capitlizing comments, changing whitespace etc) on portions. Please resubmit your patch without those changes -- better to have consistent code even if it is not necessarily beautiful -- btw, that still doesn't mean it will be accepted but it would help.

A few things to note: this is not a bug, but a feature request, which is why I moved this thread. I also noticed that you said this is part of a SoC project for the Gallery project. A patch of this sort against Smarty should definately stand on its own merits and needs but I would rather wait to apply something like this (if at all) until it was clear that your work with Gallery would be accepted into their codebase. Can you mentor confirm and/or help coordinate? Much appreciated and happy coding!

Monte, messju -- any comments?

[bharat]

Hiya boots! jablko is my summer student and I'm confident that his work is going to get committed into Gallery soon. Right now it's mainly just undergoing a UI review. With any luck it'll go into our upcoming 2.2 release.

Jablko is much more conversant with these changes than I am at the moment, but here are my thoughts regarding the 3 changes (in the order that jablko presented them):

1) We could keep {append} as our own custom compiler function, if that's an issue. I can see the feature creep argument on this one, especially since it's uncommon to be modifying variables inside the template. We try to avoid this where possible, but creating AJAX UIs on the fly is making us re-think some of the ways that we separate logic and content now that we're pushing more and more logic into Javascript in the templates.

2) It looks like we could implement the {capture append="..."} functionality as our own private plugin, but it will be less efficient than doing it in the compiler. We could extend the compiler to override _compile_capture_tag and do our own stuff there, but I'm not personally thrilled about overriding a Smarty internal method if we can avoid it. And this change looks to be pretty small.

3) We have our own subclass of Smarty so we could certainly override assign and append to allow storing into structured variables. But again, it would be nice to have this as part of the core set. It seems reasonable to me to be able to store data into structure variables since we can read from them, ie {$foo.bar} lets you read the value so {assign var="foo.bar"} should let you write it back.

Hope that helps

[boots]

Hi there bhrarat, long-time no talk

Thanks for the comments and clarifications. I will try to review the patch over the next couple of weeks and will give some more feedback at that point.

Best regards!

[jablko]

http://cgi.sfu.ca/~jdbates/tmp/smarty/200607241/patch

Thanks for your guidance boots & bharat

I cleaned up this patch, it's now much smaller. Eliminated {append} to avoid feature creap

I struggled to find the Smarty coding stanndards, do you use the PEAR standards? http://pear.php.net/manual/en/standards.php

Please let me know if additional changes are needed

Thanks again - Jack