Hello
Do for use the smarty to local (xampp, wamp) must it be installation?
Now if need to install to local, for upload to main server must work particular done or just upload codes?
Hi,
If you get Smarty working on your localhost, then it will work on your webhost. You just upload the files. Don’t forget you need a writable temporary folder for the Cache files, so your webhost needs a /tmp/ folder to be writable.
Thanks!
I work with smarty on local And I’m a rookie.I have five folders:
cache
configs
templates
templates_c
libs:=>files smarty
Which folders must be writable?
how to Windows 7 folders must be writable?
templates_c and cache if smarty’s cache enabled
folders are writables by default on windows, isn’t it ?
Smarty is about the worst thing in the world you can do to your code folks - warning you now, there are much better ways to accomplish the things smarty claims to accomplish.
– on an ongoing crusade against smarty (more accurately dummy ) Template Engine.
Thanks!
I do not know, how should understand that this folder by default is writable or not?
i am In practice smarty and I’m faced with this error:
Fatal error: Call to a member function assign() on a non-object in D:\xampp\htdocs\smarty\index.php on line 26
hum, it’s seems that your Smarty object is not (or bad) initialized …
Thanks!
hello
You say that I not working on smarty?
What are advantages or disadvantages of it?
To install I used this tutorial:
I was faced with a new error:
Warning: require(Smarty.class.php) [function.require]: failed to open stream: No such file or directory in D:\xampp\htdocs\smarty\index.php on line 4
Fatal error: require() [function.require]: Failed opening required ‘Smarty.class.php’ (include_path=‘“.’) in D:\xampp\htdocs\smarty\index.php on line 4
My professional advice is to not use smarty if you have any choice in the matter. It is about the worst open source PHP project in existence, and that’s saying a LOT. Don’t take my word alone for it, there’s a whole website devoted to exploring why the thing is a bad idea.
Thanks!
I want to speed up loading and security to take my site.
You know a better way except smart??
If your coding is to a level that you can see the advantages smarty purports to offer, then congratulations, you’ve stepped out of novice territory to intermediate. The next step is to get some books or websites that describe the MVC architecture and other design patterns in depth.
Then download and take a look at the frameworks out there - CakePHP, Symphony; and full CMS systems such as Joomla (Though Joomla uses or used to use smarty and that’s one reason I won’t touch it) and Drupal. Tinker with them, see how they tick. Unfortunately you’ll find that each one implements MVC a different way, which will make learning more difficult.
Unfortunately for you, and a lot of programmers out there, this is where PHP’s documentation begins to breakdown into a mess. That isn’t entirely surprising - the topics that lie ahead of you are more esoteric in nature and will take a while to grasp.
Smarty is bad because it violates a great many design patterns - the more you read on the topic the more this will become clear. Another reason it is bad is it puts a template engine inside a template engine - PHP. PHP was born as a template engine for C++. It has since evolved into a language in its own right, but its roots as a template engine are clear in the presence of braceless syntax and short tags.
The stated goal of smarty is separation of PHP from HTML. That’s wrong headed and stupid on many levels it’s staggering - the goal should be the seperation of business logic from display logic. There will be logic involved in building a display - this is why smarty has to have so many tags. You can separate logic concerns in a single class that I’ll write into this post for an example:
class SimpleTemplate extends ArrayObject {
private $template = '';
public function __construct($template, array $output = array() ) {
$this->template = $template;
parent::__construct($output);
}
public function __toString() {
return $this->parse($this->template);
}
protected function parseTemplate( $template = '', array $output = array() ) {
extract( $this->getArrayCopy() );
if (!empty($output)) {
extract($output);
}
if ($template == '') {
$template = $this->template;
}
ob_start();
include($template);
return ob_get_clean();
}
}
Quick rundown of what’s going on here. We are extending off ArrayObject, which lets our SimpleTemplate class act like an array when handled by the outside code. We give it a template file which will have the HTML, just like smarty. Unlike smarty that file is a PHP file in it’s own right. It will look like this.
<html>
<head>
<title><?= $title ?></title>
</head>
<body>
<p><?= $message ?></p>
</body>
</html>
So the outside code would be
$myTemplate = new SimpleTemplate('myTemplate.phtml');
$myTemplate['title'] = 'Hello Page';
$myTemplate['message'] = 'Hello World!';
// And so on.
// When we are ready to send the html out to the browser we do this...
echo $myTemplate;
This system is a pruned down version of the one I use - the complete version automates finding of the templates, throws errors when templates are missing, and so on. But as a place to start it should be fine, especially since it illustrates that smarty is making a huge mountain out of a VERY simple task - separation of concerns in code.
Thank you very much
I read this your article, On this code i will work. Although first the code is hard to understand for me, but I try to understand. Of course, I need your help too.
did this way is cause increase speed and security or just is cause separation php code of html code?
The goal is separation of concerns. Any claim that smarty or any other template engine increases security is just smoke blowing by the ignorant. If your view code is directly involved in securing stuff you’re doing it wrong (it is often indirectly involved, see below). It isn’t the duty of the template system to secure anything - the concern of templates and their handling code is to prepare the output. Brief rundown of MVC.
MVC means Model - View - Control. Code is divided into three areas.
Model is the application state and it’s data.
View is the application interface with the user - the user’s view.
Control is the code which moves data from the models to the view.
The goal of this separation is that changes to one area have no effect on the other two so long as the API (Application Program Interface) between the three is unaltered. The API between the components is kept as small as possible.
Breaking down further.
The Model is actually broken into two major objects areas - the domain model and the data models. Both models share one thing in common, they will respond to requests from anywhere in the code, but they do not initiate contact with any other area of the code. To put that another way, models do not initiate anything. Ever. A lot of PHP systems get this wrong. Models do not and should not care about control state or view state. Why? So that if the handling of either changes the model is unaffected by those changes. Again - separation of concerns.
Control is a dispatcher. It is the first part of the system to start and in most PHP setups it is the last to conclude. It looks at the request of the user and relays that request to the domain model. The domain model does authentication of the request based on the user’s permissions and gives a response back to the controller. Based both on the request and the nature of this response the controller selects a view. If the domain model returned a data model the controller gives the data model to that view and instructs the view to give the browser a response. The controller talks to the model and to the view, but neither talk back to it. The controller is bossy, it doesn’t listen to anyone.
The view composes user responses. It talks to the data model it was given. An example of a data model is a query summary. That summary object could potentially access thousands of rows of data. The view however has the job of choosing which rows are going to be used in the current response, say page 30 of 59. It will ask the data model for the data it needs based on the state of the user’s view (Page number, user permissions, etc). Once it has the data it needs it binds that onto the template objects, parses them into strings and sends that data to the browser. The view talks to the data model(s) the controller gives it and takes orders from the controller, but doesn’t talk to the controller or to any other data model.
Further breakdown would turn into a book. And further the interpretation above is mine - you’ll find people who swear the view should never talk to a model which I view as incorrect. Who knows, maybe one will jump into this thread and you’ll get to see us argue. 
As for security, securing user permissions is part of what the user object does, which as a data object means it is in the model code. The domain model consults the data object on requests. Some PHP systems have the controller run the auth. In my system the auth check is fired by the controller, but resolved by the domain controller which then tells the controller whether authentication was passed. Log in / not logged in, these are concerns of application state, or the domain model.
The view will consult the domain model to determine what options to display for the user based on their permissions, but it doesn’t directly do the checks involved - the model does. More usually the options the view will be asked to be display are already encoded in the model the view is working with.
The domain model is also the code area that determines where the data will come from - the database? the cache? the filesystem? Again, the controller and views don’t need to care about this stuff.
I would say that could be considered true if smarty completely eliminated access to PHP outside the template. However, within any smarty template you can place PHP code using {php}{/php} tags. So there is nothing stopping anyone from running queries, processing data in the template.
Within a traditional, persistent paradigm I fully agree. However, the standard in non-persistent environments is to have the controller act as a mediator between the model and view – normally the template. In that regards I believe the domain based implementation of MVC, is essentially a subset, of what the traditional pattern represents. Its not wrong, its just a different interpretation taking into consideration all the added variables of a non-persistent environment. That is probably why so many people get confused. The implementation of MVC and supporting patterns is significantly different going from none-persistent and persistent environments.
Don’t take any one person’s “professional advice” to heart. Learn about Smarty for yourself and make an informed decision. A “crusade” against a technology is only testament to it’s success, is it not?
Smarty IS about separation of business logic from presentation. However, Smarty’s take on it is that PHP code IS business logic. Just because you CAN mix PHP with HTML doesn’t make it a desirable approach. PHP sucks as a template language, and I’m certainly no the only one in this camp. The creator of symfony has a very similar outlook regarding PHP templates:
He even wrote his own engine around the same concepts. Good for him!
Also, do you think the template engines Django and CheetahTemplate for Python have it wrong too? It’s the same concept: separate programming language from presentation. It makes sense for a lot of developers.
If you like PHP as a template language, don’t use Smarty. If you want your “separation of concerns” to include the separation of PHP from HTML/CSS, Smarty does just that, along with many other great features for presentation.
That nosmarty site is mostly propaganda from a ignorant developer. It is outdated and inaccurate. Smarty is not an MVC, an comparing it to MVC frameworks is laughable. Smarty is only the View, and one approach to it. A “no” site is only testament that Smarty must be doing something right to gain such popularity, and it’s not because thousand of developers “have it all wrong.” Not everyone has the same requirements, preferences and tastes in development approaches. Smarty is great for some, not for others. Get over it.
Also, {php} tags have been long discouraged, and now completely deprecated in Smarty 3. They go against the principles of separation, and using this as an argument is baseless.
Or testament to hundreds of hours of using it and having to abandon it.
Popularity isn’t a testament to usefulness. Pet rocks where a fad. Anyone remember those stupid gem trolls? Smarty is the programmer’s equivalent - a fad, but when you take a hard look at it then its uselessness becomes apparent.
Smarty IS about separation of business logic from presentation. However, Smarty’s take on it is that PHP code IS business logic. Just because you CAN mix PHP with HTML doesn’t make it a desirable approach. PHP sucks as a template language, and I’m certainly no the only one in this camp.
For all PHP’s flaws, smarty is not the solution. It’s 10 to 20 times slower than native PHP, even with its schizophrenic and unreliable
The creator of symfony has a very similar outlook regarding PHP templates:
And I should care why? Until someone designs a framework system more than even 30% of the PHP user base is willing to get behind I’ll hardly be impressed. Symphony has some pretty serious flaws of its own (like trying to move all the controller logic into yaml files, ugh).
Also, do you think the template engines Django and CheetahTemplate for Python have it wrong too? It’s the same concept: separate programming language from presentation. It makes sense for a lot of developers.
Seriously??
Uhm, last time I checked Python lacks python tags that let you jump into and out of python mode the way <?php ?> tags allow. Why do those tags exist? Because PHP is a templating language - PHP 1.0 existed for no other purpose than to serve in this task for code written in C++. It has since outgrown that original purpose, but the legacy of its origin remains clear.
Python is emphatically not a templating language any more than Perl or C++ or Java. All of these languages have to have template engines because they have no other way to interface with the HTML code. PHP does not have this disadvantage - et voila, it has a 60% market share in web deployment. I wonder why? It’s still a template engine at heart. You can dabble with it long before you get serious with it and need to start exploring frameworks and structures.
This ease of learning leads to hundreds and thousands of programmers who, frankly, don’t know what the Hell they are doing. Smarty preys on that sort of people, and it’s sad because it handicaps them and prevents them from becoming better programmers by mis-teaching them.
If you like PHP as a template language, don’t use Smarty. If you want your “separation of concerns” to include the separation of PHP from HTML/CSS, Smarty does just that, along with many other great features for presentation.
Smarty cannot even accomplish that. It’s {php} tag is just a keystroke away. Almost every site I’ve been called into maintain that had smarty in place used those tags as well. It’s features are a joke, it’s syntax is uneven and requires constant manual reference.
That nosmarty site is mostly propaganda from a ignorant developer. It is outdated and inaccurate.
Right… 
Smarty is not an MVC, an comparing it to MVC frameworks is laughable. Smarty is only the View, and one approach to it.
Trying to sell tires without a car eh? We got great tires, but we aren’t helping you with the design of the rest of the car - that’s funny. That’s analogous to what you are doing.
Besides, there is more to the view state than template parsing. Smarty is a template parser, and a lousy one at that. That one of it’s own fanboys confuses it for a complete part of an MVC solution only reinforces my view that it is misleading and damaging code to anyone that uses it.
A “no” site is only testament that Smarty must be doing something right to gain such popularity, and it’s not because thousand of developers “have it all wrong.”
And yet where is smarty in enterprise level deployment? Thought so. Amateurs do stupid things and its easy to sell snake oil to them. I know - I was one once. I used smarty at one time - neat concept I thought. Then it became an annoyance and eventually a massive maintenance headache. Then I went back and learned how to do it right and haven’t looked back.
Not everyone has the same requirements, preferences and tastes in development approaches. Smarty is great for some, not for others. Get over it.
The only people smarty is useful to are those who’s understanding of MVC architecture is incomplete enough that smarty can sell it’s line of horse crap to them.
And I’ll not just “get over it.” Eventually code has to be maintained. If railing against smarty stops just one project I eventually have to maintain from using the POS then I’m accomplished something. Further, it is harmful code. It teaches people the wrong ways to do something. This forum is primarily an educational area. I have a right to explain my views. You have no right to tell me or anyone else to “get over it.”
Also, {php} tags have been long discouraged, and now completely deprecated in Smarty 3. They go against the principles of separation, and using this as an argument is baseless.
Deprecated is not removed. And they shouldn’t have been in there in the first place. Their presence is the least of my gripes. Foreign, often impenetrable syntax, data dumps masquerading as true debugging tools, Severely limited options for data formating forcing back end programmers to move formating logic outside the template parser, etc.
And I’ve yet to meet one designer smart enough to deal with {smarty tag} but too dumb to handle <?php ?>. That alone disqualifies it.
This could go on for pages - I’ve stated my points and I’m not going to talk in circles. I have better things to do with my time.
As already stated, PHP began as a template language, but that doesn’t mean its the correct and preferable approach for everyone.
Python is emphatically not a templating language any more than Perl or C++ or Java. All of these languages have to have template engines because they have no other way to interface with the HTML code. PHP does not have this disadvantage - et voila, it has a 60% market share in web deployment. I wonder why? It’s still a template engine at heart. You can dabble with it long before you get serious with it and need to start exploring frameworks and structures.
… and many developers don’t see this as an advantage to PHP, but moreso as a disadvantage, and leads to messy PHP mixed templates. To each their own.
This ease of learning leads to hundreds and thousands of programmers who, frankly, don’t know what the Hell they are doing. Smarty preys on that sort of people, and it’s sad because it handicaps them and prevents them from becoming better programmers by mis-teaching them.
Thanks for the gross assumption.
Smarty cannot even accomplish that. It’s {php} tag is just a keystroke away. Almost every site I’ve been called into maintain that had smarty in place used those tags as well. It’s features are a joke, it’s syntax is uneven and requires constant manual reference.
It has been stated for a long time to avoid {php} tags. This is not unlike abusing eval(), magic quotes, and a multitude of other functions in PHP that can lead to some pretty bad stuff. Don’t use {php} tags. They should have never been added, but hind site is 20/20.
Trying to sell tires without a car eh? We got great tires, but we aren’t helping you with the design of the rest of the car - that’s funny. That’s analogous to what you are doing.
You completely miss the point. Smarty is not meant to replace an MVC, and that is exactly how this comparison takes place. Smarty has been implemented in all the MVC’s mentioned on this page too, if you care to use it for your views.
And yet where is smarty in enterprise level deployment? Thought so. Amateurs do stupid things and its easy to sell snake oil to them. I know - I was one once. I used smarty at one time - neat concept I thought. Then it became an annoyance and eventually a massive maintenance headache. Then I went back and learned how to do it right and haven’t looked back.
Uh, the number of enterprise deployments are pretty staggering. Actually the ones that really “get it” are the enterprise solutions. I myself deployed it on 200 college and university newspaper sites. Hundreds of college students edited templates from every walk of life. Some developers, some designers, some completely non-technical. There was no way we could unleash everything that is PHP to them just to edit the templates. Smarty fit the bill perfectly.
The only people smarty is useful to are those who’s understanding of MVC architecture is incomplete enough that smarty can sell it’s line of horse crap to them.
Yet another stupid gross assumption.
And I’ve yet to meet one designer smart enough to deal with {smarty tag} but too dumb to handle <?php ?>. That alone disqualifies it.
That has absolutely nothing to do with anything argued here.
This could go on for pages - I’ve stated my points and I’m not going to talk in circles. I have better things to do with my time.
I feel the same way, like trying to justify mac in a pc forum. Smarty has its place. Obviously you have your own gripes with it, and for you, don’t use it. But don’t try to speak for every developer, your arguments hold little water.
hello i want use code top that write Michael Morris but one error is to code:
Fatal error: Call to undefined method SimpleTemplate:: parse() in D:\xampp\htdocs\classes\site\index.php on line 9
line 9 my code:
return $this->parse($this->template);
Oops. That example is pruned down from a slightly larger class. This should work.
class SimpleTemplate extends ArrayObject {
private $template = '';
public function __construct($template, array $output = array() ) {
$this->template = $template;
parent::__construct($output);
}
public function __toString() {
return $this->parseTemplate($this->template);
}
protected function parseTemplate( $template = '', array $output = array() ) {
extract( $this->getArrayCopy() );
if (!empty($output)) {
extract($output);
}
if ($template == '') {
$template = $this->template;
}
ob_start();
include($template);
return ob_get_clean();
}
}
Thanks!
you talk this code is example and not use self this code to program?
new error:
Fatal error: Cannot redeclare class SimpleTemplate in D:\xampp\htdocs\classes\site\index.php on line 32
my codes:
index.php
<?php
class SimpleTemplate extends ArrayObject {
private $template = '';
public function __construct($template, array $output = array() ) {
$this->template = $template;
parent::__construct($output);
}
public function __toString() {
return $this->parseTemplate($this->template);
}
protected function parseTemplate( $template = '', array $output = array() ) {
extract( $this->getArrayCopy() );
if (!empty($output)) {
extract($output);
}
if ($template == '') {
$template = $this->template;
}
ob_start();
include($template);
return ob_get_clean();
}
}
$myTemplate = new SimpleTemplate('mytemplate.php');
$myTemplate['title'] = 'Hello Page';
$myTemplate['message'] = 'Hello World!';
// And so on. // When we are ready to send the html out to the browser we do this...echo $myTemplate;
echo $myTemplate;
?>
mytemplate.php:
<?php include('index.php'); ?>
<head>
<title><?= $title ?></title>
</head>
<body>
<p><?= $message ?></p>
</body>
</html>
if i remove the line 1 to mytemplate.php to titel display <?= $title ?> and to body not something Then no error.