Smarty

[swapo]

@Swatinem
That's what I meant when I was writing about a meta format.

@Razor's Edge UK
Of course you can work around missing PHP5 functions. But the OOP features aren't
really portable back to PHP4.
Exception handling is one thing I don't want to miss.
Interfaces, a simple "instanceof" and typed arguments are necessary for consistency.

As I said before: It's not a question of "if" but of "when" PHP5 will make it's way
to a huge number of ISPs. Currently there's not one line finished as we're still discussing
the API layout so it's likely that PHP5 is the default version when Smarty 3 is
finished. Beside that, there's still Smarty 2 which is not going to die in the near
future.

[Razor's Edge UK]

I've been lucky enough to only ever work in PHP5. Prior to that it was just local home site playing in PHP4. Now I'm paid to work with PHP5. So backward compatibility is non-existant. And exception handling is great in PHP5!

[c960657]

Another suggestion for Smarty 3:
When using relative template paths (paths without a leading /) in a template, the path should be treated as relative to the template itself. E.g. if /var/templates/project1/foo/bar.tpl contains {include file="baz.tpl"}, it should include /var/templates/project1/foo/baz.tpl independant of the value of $smarty->template_dir. The reasoning is that a given template may be used in different projects where $smarty->template_dir may differ.

Also, one could argue that absolute template paths should be relative to $smarty->template_dir. Having filesystem-absolute paths in templates is usually bad coding practice, so the "namespace" consisting of paths with a leading slash could be put to better use. If someone wants filesystem-absolute paths, it can still be achieved through a custom resoucetype, "absfile:/usr/local/templates/foo.tpl".

Interpreting relative and absolute paths for non-file resource types should probably be left to the specific resource type implementation.

[Swatinem]

I thought a little about the Meta Format for templates.
Every Template Element would be a seperate object of types SmartyMetaTag, SmartyMetaVar, SmartyMetaBlock and SmartyMetaText
The SmartyMetaTemplate would contain a list of child objects... The SmartyMetaBlock would also contain a list of child objects.
These SmartyMetaElements implement a function called compile(). The SmartyMetaText would just return the text and the SmartyMetaBlock would first compile all of its childs and then do with its compiled content whatever it wants

This would solve a few problems with block nesting and would give a lot more freedom because the Block actually can use its compiled content.

Perhaps we still have to differentiate between SmartyMetaVar's that are for their own or ones that are arguments to a tag.

[Swatinem]

It's been a long time. Any new ideas? When do you want to start coding? I would like to help if i can...

[mohrt]

There are some things brewing... I'll be announcing some direction early in the new year.

[peekaa]

Well there is my thoughts about that.
100% PHP5. Latest as possible. We have allways smarty 2.x.

Smarty 2.x has all needs you need. There is only 1 thing that can allways be better. Speed. So use PHP5 new things to make smarty3 faster then ever.

Smarty is somehow good, it dont depend on some other package what is some cases in good, and some cases bad. Its not core thing, but still its nice to see when smarty can communicate with other open source projects.

There are some things that comes in future or atleast i think it comes. One thing is encoders and optimizers. Ssme thing as above, its not core thing, but its nice if smarty knows those things. Its just speed thing.

Other thing is AJAX. Actually AJAX has almost nothing to do with template engines, but still its a option to think. Smarty is supposed to make things easyer, why not that part too.

Just some ideas, maybe it helps.

[Swatinem]

The only thing i could think of how Smarty could help AJAX is to have an option to send the pages as Content-Type: text/xml. Alternatively you could also add a option to directly gzip the output via Smarty so you dont need to do that yourself. But thats not as important as Content-Type: text/xml oder application/xml or whatever the content type ist.

[amagrude]

1. Easier deployment - It would be damn handy to have 'include_path' like functionality for user developed functions, modifiers, filters and templates. We're able to override a function in Smarty2 now and get basically that for templates, but the rest are interwoven with the core Smarty files. It would simplify upgrading and file management if we could (for example) divide our Smarty installation into three discrete directories: Smarty, Formtool, and our developed modifiers, filters and functions.

2. Modifier Array handling - The current calling semantics for modifiers constrain them to only operate on the value of an associative array and preclude operation on the key, to the point of hiding it from the modifier code. This precludes the development of modifiers which operate on arrays - without twisting the syntax into basically RPN format. As an example, the current implementation forces the prototypical array_key_exists wrapper (we must run with security on) to be written so:

{if 'email'|isset:$ErrorVariableList}

instead of the more consistent (and, IMO, intuitive):

{if $ErrorVariableList|isset:'email'}

I don't see a way to do this in a backward compatible way with user developed modifiers, but the existing modifiers could be extended to directly handle arrays.

Andrew

[pt2002]

Are there any news about Smarty 3 ?

Now, with EZComponents an Zend Framework, the only thing missing is a good template engine.

greetings
pt2002

[Ruud]

I want to add some things to the XML discussion. The advantages are clear for everybody. However, it doesn't look like Smarty 3 will support XML tags. There is only one reason to not choose for XML, and that's because XML isn't meant for defining loops (etc.), it's meant for defining data. But I don't think anyone would have a problem with that (what are the practical problems?).

Disadvantages like the header footer problem can be easily solved this way:

[mohrt]

Have you ever handed an XML/XSLT template to a web page designer and watch their eyes glaze over? XML notation is perfect for computer-to-computer data handling, but not well suited for human-edited templates. That is the #1 reason why Smarty templates do not follow XML compliance. Also, since template files are not typically seen/parsed by programs outside of Smarty, it wasn't such a priority either. Now the OUTPUT of the templates can certainly be XML/XHTML compliant, and typically they are.

The one common occurance is HTML editors that complain about tag syntax. The editor is making an assumption that it is editing an HTML file, not an intermediate template file. Sometimes this can be remedied by tags like <!--{ }-->, or configuring the editor for Smarty syntax.

XML compliant templates can have its purpose (even if its for arguments sake), and this may at least be an option... configurable template syntax and/or drop-in compilers. These things are on the list.

[Hielke Hoeve]

[Ruud]

[boots]

I think I've made my points about XML and its (un)suitability already though I will point out that the most promising XMLish approach in my mind is something along the lines of TAL. Unfortunately, that is not XML compliant either as it mangles the attribute space of XML tags.

Re-iterating Monte's comment, a drop-in compiler model seems like a nice compromise -- use any syntax style you want as long as you implement a suitable compiler for your grammer. It seems to me (and I've proposed this before) that this begs for separating the compiler into two distinct parts, namely a front-end and a back-end with an intermediate, generalized and standard format in-between. The front-end compilers (ie: "source compilers") would compile to the intermediate form and the back-end compilers would compile the intermediate form into the desired "object code" (eg: PHP). This also opens the door to optimization strategies as the intermediate format could potentially be analyzed and transformed in various ways. It sounds good on paper but it also seems a little overblown.

Never-the-less, this is one of my favourite ideas as a path to fully modularizing and abstracting Smarty's capabilities. This does leave an open question: what should the intermediate form's data strucuture look like and what is the minimal set of tokens/operations that it would need to support?" The way I phrased that probably suggests a token stack together with associated data hashes for the token data (so everthing can be readily serialized) -- but I suppose other interesting possibilities exist. Then again, it may all be crazy talk