Has anyone used Smarty?

[BigBison]

http://smarty.php.net

I may just resurrect the core object from my 1998-vintage SSJS CMS and build what I need around that. With tools out there like Smarty, so much of the work is done for me that it wouldn't be much code at all. Now that I've "discovered" Smarty, I don't understand why so few CMSs are aware of it. The sundry apps out there which implement some sort of skin/template system each re-invent that particular wheel, typically in quite the ugly fashion compared to the elegant solution offered by Smarty.

It also seems that it would be easier to get skins contributed to a given project if it were using some kind of standardized templating engine. While my questions about Smarty are mostly nuts-and-bolts (how to call the template, whether to make my browser-sort script part of the application logic or retool it as a Smarty extension because it's really display logic, etc.) I am curious whether or not anyone has ever developed a template for a project which uses Smarty.

[Pauly]

Not come across this but it sounds a lot like the template engine I documented last year(I'm sure there are differences), and is still in development - but for an ASP client, not PHP.

Nothing special to be honest, a lot of developers custom develop systems like this, but it does cut the developer a lot of slack.

[BigBison]

That's exactly my problem. Everybody has rolled their own template engine, most of which include PHP (or what-have-you) code in the template or rely entirely on HTML comments. I do think Smarty may be something special, judging by the caching. Also, it's part of the PHP project, which to me is a huge plus.

[sonicgroup]

I've used it before. It's extremely flexible, but also very daunting. It's almost like learning a new language.

I think that Smarty has a very narrow set of applications that it's suitable for. Your average website is not going to realize the potential of Smarty (and may actually be slower because of it). There are many other good caching template engines out there as well.

[BigBison]

I don't make 'average' websites... :lol: ...but thanks for your concern!

Care to elaborate, or perhaps provide an example of another caching template system that you like?

[BigBison]

...or below-average sites, wisenheimers...

Other PHP Template Engines:

http://wact.sourceforge.net/index.php/PhpTemplateEngines

[sonicgroup]

That's a good list. I was going to list Savant and HTML_Template_Flexy from PEAR.

[BigBison]

The WACT site has an incredibly detailed Wiki, with lots of useful and valuable information. Unfortunately, that's the most useless Wiki design I've seen, as there is no menu -- g'head, try to navigate, or find your way back to a page if it isn't in the 'back' button list. Grrr.

[BigBison]

Sonicgroup's two choices cut right to the quick of the Smarty alternatives. I'm still trying to figure out what to make of Savant, which isn't a template engine. There's lots of lively debate out there concerning template engines, and whether or not to use PHP in the template. Then, the debate morphs into whether or not PHP is itself merely a templating language. Further on, you'll find others who disavow PHP, ASP and JSP altogether, stating the only real standard for templating is XSLT.

http://www.massassi.com/php/articles/template_engines/
http://www.phppatterns.com/index.php/article/articleview/4/1/1/
(two examples, both from the savant homepage)

There's a security issue to consider as well. Without divulging any details, I'd like to allow broad contribution of skins to my site. By choosing Smarty, I wouldn't have to audit every skin for potential exploits like I would a template system like Flexy, which has tremendous appeal to me because it's something like 1/10th the size of Smarty. Either option clearly allows me to include or exclude content based upon the users' privileges.

I'm not at all sure I can do that with XSLT. I may end up with several templates instead of one template with conditional logic. You can of course use conditional logic within XSLT, but I don't think I can pass application (session) data to such a template like I can so easily with a template engine. This is a crucial point as it effects the design considerably.

Or maybe I can...

[sonicgroup]

If you're looking at the security side, it may be worth investigating doing something like most CMS and forum software does - template files that have special sequences to replace characters (i.e. {VARNAME}). This is the basis for how Smarty works, although they build loads more functionality into it than a simple str_replace().

Parsing template files in that manner avoids having malicious code executed by only allowing HTML (assuming you disallow JS by some method). There's no surefire way of doing this other than a manual audit however.

As for the debate about the templating thing: There's a few crowds - the separationg of presentation and logic crowd - the templates are the spawn of the devil crowd - and the templates, eh? crowd. I'm more in the last crowd. If a template suits the purpose and functioning of the site, so be it. If not, why bother? I much prefer to take an MVC approach and separate the levels of logic versus separating logic from presentation. Because, let's face it, there'll always be some point at which logic finds it's way into a template (Smarty for instance - a logic-based template engine).

[BigBison]

Ah, yes. I deleted the paragraph I started about my CMS following MVC principles, just like my last one attempted but couldn't achieve given the technologies on hand at that time.

I don't have lots of time to code it, so I'm writing a quick, down-and-dirty CMS. I'm looking for a plug-in solution like a template engine to take care of "V". In fact, I was talking crazy earlier in this thread about redoing browser sort as a Smarty extension. Browser sorting ought to occur within "C".

But, will that controller decide which version of my XSLT stylesheet to serve, or pass it variables through the XML? Don't anyone get ahead of me just yet, I need to be studying not posting! XSLT solves the same problems Smarty does, regarding security and allowing easier contributinon -- it's a standard.

Model View Controller

Model is the backend logic -- what content makes up this page, where is it kept, how is it retrieved. The controller decides which view of the model the user sees.

Smarty's disadvantage is size, and being too powerful. Smarty allows lots of the M and C stuff to be done in V. Just because one can, doesn't mean one should, however.

[sonicgroup]

And that's exactly the point I was getting at with my original post. Don't get me wrong, Smarty is insanely powerful, and very feature complete, but it's overkill for 90% of the applications out there, which is why I suggested some other alternatives. For general templating, HTML_Template_Flexy is a perfect solution. Small, lightweight, fast, and only concerned with templating. Combine that with using XSLT, and you get an even more robust solution, with less processing.

[BigBison]

I'm trying to separate my application logic from my presentation logic.

Whether or not to display a login or quick-post box depends on whether or not the user is logged in. That's a site policy.

If a user is logged in, the controller (which also sorts the browsers and determines the language to be used) instructs the model to include a logout instead of a login, and a quick-post box.

In the XSLT template, the proper area of the page for login/logout simply consists of two different transformation rules, one for each condition, with no conditional logic necessary.

Likewise, the template needs only a transformation rule in the correct area for the quick-post box. Thus, the template designer could choose to omit post capability by omitting the rule, yet is unable to override my site security policy by allowing anonymous posts.

The conditional logic capabilities in XSLT are great if the template designer chooses to alternate background colors from one post to the next. I'm not sure I need the combination of template engine + XSLT. One thing I've yet to work out is caching, however.

[BigBison]

Oops. I said "core routine" in my OP when I meant "core object".

Edit: Made the change for you in OP, so as not to confuse a reader starting from the beginning.
- the_pm

[BigBison]

Heheh... careful about even getting started editing my posts to be less confusing!!! But in this case, thanks!

[BigBison]

I may very well start another thread about this little CMS project of mine. Until then, I'd like to close this thread out by stating that MVC is in the eye of the beholder, as it is just a theory. For instance, in my concept, action links like post, edit, quote, reply or report, only appear if the required conditions are met, such as permission level of the user or time constraints. For example, after 15 minutes, your post won't even have an edit link and unregistered / not logged in users won't even see action links. Why make the server do the work of serving an error page?

But I consider that application logic, not display logic. Which is what I mean by in the eye of the beholder. The next guy may very well see the above paragraph as display logic, certainly not application logic.

[sonicgroup]

I consider that display logic for the simple fact that you have to create those options in the first place - it's easier to just hide them rather than use application logic to determine which, if any, should be shown.

[BigBison]

No, hiding them is display logic. Under my (germinating in my brain) system, the template (XSLT) displays every tag it's fed. If there's output from the system to hide, no transformation rule is applied. You're saying whether or not a user is logged in should be determined by the display layer, which needs to happen in order to hide anything. Doesn't that put external logic into the display layer?

I'm still working out caching. However, one benefit to using XSLT is XML-capable browsers like Opera, Firefox, etc. It may be possible, if I design this correctly, for those browsers to be fed the XML. The XML files all link the XSLT as an external stylesheet, the transformation of XML to XHTML 1.1 is then done on the client side. By caching the bulky XHTML code (which is what the XSLT template is, really) the same way a CSS stylesheet or javascript is cached and only transferring XML snippets, performance is optimized. The server doesn't have to execute a transformation each time, so processor cycles are saved as well as bandwidth.

XML browsers can either display XHTML 1.1 directly, or they can display an XML file and its associated XSLT stylesheet. The stylesheet determines the DOCTYPE, there's no reason it can't transform the XML into HTML 4.01 other than why would anyone want to?

[sonicgroup]

That was my initial point. You save server processing time by taking advantage of the fact that the "presentation layer" is essentially cached, and any transformations happen at the client level, rather than the server level.

That is what I meant though - hiding them is display logic. Perhaps I worded my response a little ambiguously. What I should have said was that there are operations in the application layer to create these items. It would be easier/better performance-wise to create all these elements and have a simple boolean check at the display layer to determine visibility, rather than having the application logic determine what to show and then only create the necessary items, and then feed that to the display layer.

[BigBison]

What I'm trying to learn about XSLT right now is if a template can include another template, like Smarty. We'll agree to disagree on how to define application vs. display logic. We can pick this thread up again once I have some code up.

I have a (loose) requirement that this CMS work within a shared hosting environment. Getting XSLT to happen without requiring root access, or a Tomcat-enabled host, is still the trick.

[BigBison]

I've recently become enamored with "PHP Architect" magazine. They offer both PDF and print versions. On their website, you can download a free issue in PDF format. A featured article in the free issue explains MVC architecture:

http://www.phparch.com/

XSLT can be accomplished with PHP. So, Tomcat (Java hosting, whatever you want to call it) isn't required. PHP 5 is better than 4 for anything XML-related. However, finding PHP 5 on a shared-hosting environment isn't all that easy at this time.

Of my four shared hosting accounts, New York Internet has said they may be able to provide PHP 5 for me so I'm waiting to hear back. Canada Web Hosting says they're working on a new server (cluster in their case) but currently have no ETA and don't think it will run 5. Icelab has said PHP 5 is coming in the future, but they have no ETA either.

Nor does my Johncompanies VPS. Their VPS software is considerably different than the industry norms, in fact a fresh account from JC only takes up about 75KB of disk space. It isn't like a Virtuozzo-based VPS where Apache is its own installation in your user space. Of course, I can install Apache in my space, but I'm currently waiting to hear back from tech support (who have been most responsive all day) before proceeding.

Which begs the question, since I'm installing Apache, should I go with 1 or 2? Anyone?

[BigBison]

Looks like I'll be installing Apache 1:

http://www.php.net/manual/en/faq.installation.php#faq.installation.apache2

[BigBison]

"MVC Architecture" falls into the class of design patterns. A design pattern is a model used to help solve a specific problem, in this case Content Management Systems. Design patterns can be applied to web development in other ways as well. At some point, this thought and the link which follows should be expanded upon in the "Web Design" forum, if anyone else wants to do that I won't mind!

http://37signals.com/papers/introtopatterns/