Smarty

[mohrt]

Some interesting things happening in alpha lately.

First, we are proposing to deprecate both {section} and {foreach} in favor of a new {for} function for looping. Examples:

[conner_bw]

Hi, please look at my project sux0r.org which wraps and extends Smarty and SmartyValidate classes. I'm a fan of Smarty, I use it everyday, so don't take the following 2 suggestions as flamebait, but rather constructive criticism.

1. Location of templates, templates_c, and cache are in the wrong place.

Separating business logic from template logic in the real world means keep the designers out of the code that actually does real work.

Currently, Smarty encourages coders to put their templates in a subdirectory of the code. That's fine for the coder, saves time, in not clicking around looking for templates. But when it comes to working with a team, on large projects, this means designers are mucking around in the same directories structure as the coder. Also setting permissions on templates_c and cache on a per directory basis.

In sux0r, I look for Smarty templates in two places. First, in a directory called templates located off the root, and if I can't find it there I cascade down and look in the subdirectory i.e. how it is now. Furthermore, templates_c and cache are also moved to subdirectories in a separate temporary directory. Making it easier to manage permissions and not mess up CVS/SVN with a bunch of individual .ignore lists.

Of course, the fact that I was able to do this with Smarty in the first place is a good thing. It shows that it's very flexible. The fact that it's not the default is counter-intuitive.

2) Renderer objects, not "plug-ins"

A few months ago I stumbled on a suggestion in this forum for object notation in Smarty. I figured out thanks to someone smarter than me that instead of writing a bunch of plug-ins I could just do

[Fenn]

[mohrt]

If you notice in alpha, you can create multiple instances of template objects:

[rodneyrehm]

First off: way to go. What I've seen thus far looks

Why was PHP's autoload abandoned? What's bothering you about the way SPL autoload works? Not that I miss it, but i don't get the point of getting ridd of it, since it perfectly suits my needs.

There's already been questions about caching gzipped output and saving the Content-Type header along the cached output. What i'm missing here is a rather flexible approach to the If-Modified-Since issues. In Smarty2 caching headers were practically ignored if {includes} or non-caching functions/blocks were used inside the template. I would *really much* like a way to specify if the contents of those "dynamic" parts really require the loading of the page, or could just return a freaking timestamp telling the last-modified time. That way you actually *could* build cache-friendly applications, without losing the benefits of Smarty's great flexibility. If dynamic contents could tell their (real) modification times, deploying cache-friendly pages would not be rocket-science and thus far more applied than they are today. I'd appreciate it, if constructs obstructing the very simple handling of If-Modified-Since/Not Modified could be queried if they actually changed since the given timestamp. All constructs now seem to be separate classes, therefore it should seem fairly easy to have them implement a contentChangedSince()-method. Programmers intending to make use of the-more-useful-HTTP-stuff could have their proprietary constructs react to If-Modified-Since headers. Getting what i'm talking about?

It would also be nice if a non-caching function nested inside a non-caching block would not result in the function being called without arguments, when reading from cache. (A bug in Smarty2 that drove me crazy like nothing else)

Some people use Smarty to generate all sorts of output. X/HTML, Javascript, JSON, XML, younameit. I pretty much hate building XML-docs without my DOM. I don't get the use of Smarty for merely calling json_encode from within the template. I feel the urge to run away when seeing PDFs generated the same way. Yet i still do all that absurd crap - just to have one single interface for controlling the output my application generates. I would love to see some functionality to handle the same data being distributed in various formats (html,json,rss,atom,xml,pdf,..). Primarily functionality that acts like another cache-group on top of the same template-resource (so flushing one template's cache-group gets ridd of all formats derived from that data-set). Seeing "self-compiled" (php-only) templates in Smarty3 should blast my initial points into oblivion, since no text-based template has to be launched to utilze smarty's output cache.


In short:
* Enhance dynamic functions/blocks with the functionality to determine if a »304 Not Modified« can be sent, although the function/block might be declared dynamic.
* Provide abstraction for different formats for the same data-set, with the goal of simplifying the caching of the same data in different formats. (practically introducing "template-groups")

[mohrt]

[rodneyrehm]

[mohrt]

[DarkBorg]

Will smarty be completely camelCase? Would be cool, this is one thing about Smarty 2.0 that bothers me a bit...

I took a look at the Sourcecode, looks sexy

[douglassdavis]

I'm pretty excited about 3.0. Is there a comprehensive list of all of the anticipated features anywhere?

Also, if I can contribute to coding or anything else, let me know how.


thanks.

[mohrt]

[mniskanen]

[U.Tews]

Markku

This will not be a problem at all. Smarty3 alows to assign variables to individual templates. Your class could look like this:

[mniskanen]

[c960657]

Perhaps I am joining the discussion a bit late, but hopefully not too late I have not studied Smarty3 closely yet, so my comments are mostly based on experiences with Smarty2.

1. It would be convenient if custom modifiers had access to the Smarty and Template instances like template functions have.
   
   
2. When I make custom template functions, I often add support for an assign parameter like the one for {cycle}, i.e. {cycle values="a,b" assign=myvar}. I suggest adding an assign modifier modifier that can be used with all template functions for assigning the output to a variable, i.e. {cycle|assign:"myvar" assign=myvar}.
   
   
3. If you have a big HTML file, it is useful to split it up and put the individual parts in seperate files that are included using {include}. To do this in Smarty2, the parent template file must have its own path hardcoded, e.g. {include file="very/long/subdir/structure/part1.tpl"}, or it can look it up using {assign var=dir value=$smarty.template|dirname}{include file="$dirname/part1.tpl"}. It would be nice with an easier way to do inclusions using relative paths.
   
   
4. I have a large number of loosely coupled projects that each offer some Smarty plugins. In order to allow Smarty to discover these plugins, I must either set $smarty->plugins_dir to a big array of all projects, or I can set it to one dir that contains symlinks to all other projects. Neither is easy/cheap to do at runtime, so I currently use a command-line script to setup these paths whenever I add a project. It would be convenient with some kind of callback mechanism (a la autoload for classes) that is invoked when Smarty needs the path to a particular template and/or a callback when the compiler is invoked. This would also allow the automatic creation of compile_dir's at runtime and other expensive operations that are only done in the relatively rare occasion that a template is compiled.
   
   
5. In Smarty2, custom resource types are 2nd class citizens compared to the file resource type that is treated specially many places in Smarty.class.php. I hope Smarty3 will have a cleaner cut so that custom resource types become as powerful as file resource types (it looks like this is already the case).
   
   
6. As I understand resource types, they can be considered "virtual filesystems", i.e. places where templates are stored. This understanding seems incompatible with the new php resource type - php resources are files in the filesystem just like file resources, just with a different syntax/semantics. I suggest an alternative approach: Resource types are just places to store files. Whether the file is interpreted as Smarty template code ({html_table loop=$foo}), pure PHP (<?php bar(); ?>) or perhaps some future XML-Smarty-variant (like the syntax used in ASP.NET, <smarty:html_table loop="$foo" />) is determined by something similar to a MIME type reported by the resource implementation. This pseudo-MIME-type (or "syntax type") maps to individual compilers (in the basic setup this is the existing Smarty_Internal_Compiler and an almost empty class that basically just passes PHP files through). The file based resource can return the type based on the file extension (.tpl, .php and .xtpl for the three examples) - or perhaps it can be contained in the template itself (like the XML prolog, <?xml version="1.0" charset="ISO-8859-1"?>). The string based resource type can use a syntax similar to the one used by the data: URI scheme, e.g. "string:type=tpl,{$foo}" or "string:type=php,<?php echo time() ?>".
   
   
7. A general method for returning metadata about each resource (as described above) would also make it possible to specify settings per file that can currently only be specified globally, e.g. $left_delimiter, $right_delimiter, $compile_check etc. These can either be specified by the resource implementation (similar to HTTP headers), or specified inline (like the XML prolog).
   
   
8. I'll be happy to discuss or elaborate these suggestions, or to tell about how we use Smarty in the company I work for. I'll probably have more comments when I get a chance to think more about this
   

To what extent is Smarty3 supposed to be backwards compatible with Smarty2?