Smarty Forum Index Smarty
WARNING: All discussion is moving to https://reddit.com/r/smarty, please go there! This forum will be closing soon.

PHP in Templates with 2.5.0...
Goto page 1, 2  Next
 
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    Smarty Forum Index -> General
View previous topic :: View next topic  
Author Message
Panama Jack
Smarty Rookie


Joined: 23 Jun 2003
Posts: 16

PostPosted: Mon Jun 23, 2003 7:57 pm    Post subject: PHP in Templates with 2.5.0... Reply with quote

Ok, I have a problem and if there isn't a solution I will have to stick with an older version of Smarty. Here is a simplified example.

PHP side...
Code:

for($i = 0; $i < 5; $i++)
    $myarray[$i] = $i;

$smarty->assign("myarray", $myarray);
$smarty->assign("count", $i);


The template...
Code:

<table>
    <tr>
        <td>
            {php}
                for($i = 0; $ < $count; $i++){
                    echo "$myarray[$i]<br>";
                }
            {/php}
        </td>
    </tr>
</table>


The above works like a charm using Smarty 2.3.1 but fails miserably with Smarty 2.5.0. None of the templated variables are even passed to the PHP part of the template.

If anyone tells me to use function libraries or the section command I am going to beat them about the head with a Smart Stick until they get some intelligence.

The above example is an over simplified example. I am using templates that take generic data supplied to them through a smarty template and then it is heavily massaged depending upon the template used for the data. If support for direct use of PHP code inside a template has been removed then I will have to stick with Smarty 2.3.1 for my application work and avoid all contact with 2.5.0.

I would like to use 2.5.0 so if anyone has a solution please let me know as the online docs are about as obtuse as you can get.
Back to top
View user's profile Send private message
messju
Administrator


Joined: 16 Apr 2003
Posts: 3336
Location: Oldenburg, Germany

PostPosted: Mon Jun 23, 2003 9:42 pm    Post subject: Reply with quote

support for direct php inside templates has not been removed from smarty, but direct access to template-variables has been removed.

if you don't accept any wrapping and don't want to take any overhead to re-import them into the scope of your {php}-block you'll have to stick to 2.3.1, sorry.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mohrt
Administrator


Joined: 16 Apr 2003
Posts: 7368
Location: Lincoln Nebraska, USA

PostPosted: Mon Jun 23, 2003 10:03 pm    Post subject: Reply with quote

Sometimes I wish {php}{/php} was never introduced. Smile Seriously, there should never be a need for doing this if you use the template engine for what it was designed to do. I won't regurgitate the reasons here, but if you give us some explicit examples of what you are trying to accomplish, maybe we can give some pointers.

Monte
Back to top
View user's profile Send private message Visit poster's website
Panama Jack
Smarty Rookie


Joined: 23 Jun 2003
Posts: 16

PostPosted: Mon Jun 23, 2003 11:59 pm    Post subject: Reply with quote

There are many reasons to use PHP within a template.

By removing the ability to use PHP within a template you severely limit what a person can do with a template. Plus the so-called security concerns I have seen voiced are nonsense. If someone gets far enough to tamper with templates then the server has far bigger security concerns.

The Smarty Template system is very nice but since 2.3.1 it seems to have limited itself severely whith the exclusion of direct PHP support within templates. A template system should be highly flexible and allow the user alot of freedom.

Sadly it looks like I will have to stick with 2.3.1 and recommend to everyone that uses any of our products that if they have Smarty 2.5.0 installed they should revert back to 2.3.x version if they want full functionality. Either that or make a patch to 2.5.0 so it can revert to supporting template variables within the php code portion of the templates.

I think you guys have shot yourself in the foot by excluding this ability.
Back to top
View user's profile Send private message
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Tue Jun 24, 2003 2:09 am    Post subject: Reply with quote

Hi Panama.

If you mean that there are a lot of reasons to execute code within a template, I hardly need remind you that Smarty provides many different ways to accomplish exactly that. You can create plugin functions, modifiers, filters, your can register objects--why you can even ASSIGN objects. There is also the little matter of include_php.

BUT, using {php}{/php} is no different than forgoing Smarty altogether and using <?php ... ?>. Your problem is not that Smarty won't do what you want -- your probelm is that you refuse to partition your application code more logically. Further, there are many reasons NOT to use PHP within a template and you are doing yourself, your customers (and apparently the Smarty developers who I might add spent a lot of time considering these interactions) a diservice by ignoring that issue.

Look at your example--you use a PHP for loop when you know full well that Smarty supplies its own {section} syntax for looping. Is that really the reason for your comments? Why would you even want to do that? Who benefits by that? If you want a PHP loop, write it in PHP, where it belongs. By the way--keep your smart stick handy. SOMEONE NEEDS IT.

Security may not be a concern to you or your implementation, but that doesn't mean it is nonsense. For example, some people make restrictive template features available to end-users. You may not understand or appreciate the security but your disparaging remarks are not only off-base, but they border on the ludicrous.

I *DO* agree that template systems should be highly flexible and allow the user freedom. I disagree strongly with your implication that Smarty is otherwise.

Face it--you aren't looking for a template system, you are looking for another language altogether.

happy coding!

ps. as mohrt suggested, if you provide some concrete samples you will likely find several people who are willing to help you in thinking about re-partitioning your application logic. That assumes, of course, that you want some constructive help.


Last edited by boots on Tue Jun 24, 2003 2:28 am; edited 5 times in total
Back to top
View user's profile Send private message
mohrt
Administrator


Joined: 16 Apr 2003
Posts: 7368
Location: Lincoln Nebraska, USA

PostPosted: Tue Jun 24, 2003 2:14 am    Post subject: Reply with quote

Panama Jack wrote:
There are many reasons to use PHP within a template.


You mean there are many reasons to require application logic within a template at runtime. That's right, but this can be done much cleaner with a custom function, or {php_include ...}. But, there is nothing stopping you from using your beloved {php}{/php} tags Wink

Panama Jack wrote:

By removing the ability to use PHP within a template you severely limit what a person can do with a template.


No one removed the ability, you can still use {php}{/php} tags. We just don't recommend them, there are much better ways to accomplish what you need.

Panama Jack wrote:

Plus the so-called security concerns I have seen voiced are nonsense. If someone gets far enough to tamper with templates then the server has far bigger security concerns.


Giving edit access to templates without giving access to the full power of PHP is an absolute must for me and many others. This is not uncommon.

Panama Jack wrote:

The Smarty Template system is very nice but since 2.3.1 it seems to have limited itself severely whith the exclusion of direct PHP support within templates. A template system should be highly flexible and allow the user alot of freedom.


Again, the ability is not removed, just not recommended. There are also no imposed limits, you can do everything you can do with {php}{/php} tags, but in a cleaner method, ie. sticking to the business logic and presentation logic separation.

As for access to assigned template vars, it was never documented or supported. Because the vars used to be exported to the template namespace, you could access them just by using $myvar. extract() is an expensive and unecessary step, so it was removed. So to access them, do this:

{php}
echo $this->_tpl_vars['myvar'];
{/php}

I'll go to say this is still undocumented and not officially supported, but it should work for quite some time Wink

Monte
Back to top
View user's profile Send private message Visit poster's website
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Tue Jun 24, 2003 2:23 am    Post subject: Reply with quote

mohrt wrote:
{php}
echo $this->_tpl_vars['myvar'];
{/php}

I'll go to say this is still undocumented and not officially supported, but it should work for quite some time Wink


Monte, is it not better to suggest

Code:
{php}
echo $this->get_template_vars('myvar');
{/php}


instead of direct access to the internals?
Back to top
View user's profile Send private message
Panama Jack
Smarty Rookie


Joined: 23 Jun 2003
Posts: 16

PostPosted: Tue Jun 24, 2003 2:43 am    Post subject: Reply with quote

Thanks for that information and I will try it to see if it cures the problem.

One thing, why not make that an OPTION in the config. This way a person can select if they want the template variables directly accessable by imbeded PHP code. For those that are security minded they can have the option off but for those that would like the flexability they can have it enabled.

That would seem to be something that caters to everyone's needs.

Now the main reason for not using function libraries is you end up with code scattered all over the place. Function libraries are GREAT for code that is going to be reused by many templates but in many cases where something is specific to only one template using a function library is overkill. It would be a pain to have to have half a dozen function files open along with the template while debugging or creation. It is far easier and simpler to have one small file instead of the half a dozen smaller files. It also makes following the template coding far, far easier for anyone that takes up the project at a later date.

And yes I do find the section command to be annoying. You have a PHP based template system and instead of using the same syntax that is used by PHP (while, for, ect) you created something totally different to accomplish the same goal. Why should there be a need to learn new programming commands for a PHP based template system? Wouldn't it be far easier to make the implimentation of those commands the same so it is easier for people to program?

One thing I have learned as a programmer is people will find ways to use things you write that you never conceived. So just because you can't envision someone using your system the way I am doesn't mean it is wrong.

Please give consideration to adding a configuration toggle to allow people to access template variables with embeded PHP code like Smarty 2.3.1 if they so wish. It would add greater flexability.
Back to top
View user's profile Send private message
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Tue Jun 24, 2003 3:04 am    Post subject: Reply with quote

Hi Panama.

I do hear you, though I still agree with Monte and messju about this Wink

As for a practical solution, though it is not very performance oriented, you can write a simple prefilter that automatically inserted

Code:
extract($this->get_template_vars());


as the first line of any found {php}{/php} block. That way you get the same behaviour you expect at the cost of a prefilter and doing an implicit extraction of the template vars. Well, at least it should work.

I can't talk for the developers of Smarty, but I do believe that one intent for Smarty (a guiding principle, so to speak) is to eschew the very design pattern that you are persuing. I won't say it is not valid or that your implementation isn't clever but I do think it is at odds with the goals that have been set for Smarty.

I see the desire to use PHP directly in Smarty as a short-cut to abstracting your code. This could very well be a relevant use for you but I *suspect* that that concept won't garner much traction with most users.

Finally, I tend to agree that {section} may not have been the 100% best implementation option, but that's what it is Smile. It was designed for a different audience than PHP programmers and it is not a 100% functional equivalent for PHP's 'for'. Again, Smarty provides a mechanism (at least in CVS) for you to build your own custom iterators. Several discussions on this forum have also looked at creating inline "macros" to enable cool things like fast template based recursion functions.

Greetings.
Back to top
View user's profile Send private message
mohrt
Administrator


Joined: 16 Apr 2003
Posts: 7368
Location: Lincoln Nebraska, USA

PostPosted: Tue Jun 24, 2003 1:23 pm    Post subject: Reply with quote

[quote="boots"]
mohrt wrote:


Monte, is it not better to suggest

Code:
{php}
echo $this->get_template_vars('myvar');
{/php}


instead of direct access to the internals?


You are right... I forgot about that (recently added) functionality, largely because I never use it Wink

Monte
Back to top
View user's profile Send private message Visit poster's website
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Tue Jun 24, 2003 10:54 pm    Post subject: Reply with quote

Actually, Monte, to be honest about it I was doing the same until recently when Messju introduced me to the new syntax. I would love to see more of the internals brought out into the API as presently, there is a very real danger that plugins (and especially compiler plugins!) written for a specific version of Smarty will not work with other versions of Smarty.

xo boots
Back to top
View user's profile Send private message
messju
Administrator


Joined: 16 Apr 2003
Posts: 3336
Location: Oldenburg, Germany

PostPosted: Tue Jun 24, 2003 11:07 pm    Post subject: Reply with quote

but there is "a very real danger" in exposing internals, also, IMHO Smile
if they are public, you cannot change them without BC-issues, this takes away flexibility for the developers/development. sth. like this can kill a whole project.

[edit: just curious: what "new syntax"? i was sure i followed recent development Smile ]
Back to top
View user's profile Send private message Send e-mail Visit poster's website
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Wed Jun 25, 2003 3:37 am    Post subject: Reply with quote

@messju:

- Well, fairly new to me is the $this->get_template_vars().

- I didn't mean expose internals--I meant create an API level interface for those internals that are most-often leaking into external codes. You make a good point though, so I while I want a more uniform access, if it is done at all it should be done after much thought.

xo boots
Back to top
View user's profile Send private message
Panama Jack
Smarty Rookie


Joined: 23 Jun 2003
Posts: 16

PostPosted: Wed Jun 25, 2003 9:46 pm    Post subject: Reply with quote

boots wrote:
Hi Panama.

Code:
extract($this->get_template_vars());




Thanks, that works like a charm but it should still be added as a togglable option in the configuration. There shouldn't be a need to add the above for every iunstance of {php}{/php}. I would still like to see this as an option in future releases.

One thing a developer has to do to maintain a stable base of users is continue to maintain "Backwards Compatability" with earlier versions. Otherwise you end up irritating people who have used the product. When someone who has been using one version of an application finds out that when they upgrade nothing they created works they will tend to either stop using the product and find one that seems more stable or continue to use the outdated version of the product and tell others they must use the outdated version.

Look at it from a companies point of view. Say you have created web sites with hundreds of templates. If you want to upgrade to the latest template version you find that most of those hundreds of templates nolonger work. The developers of the template engine tell you that you are out of luck and they are not going to support backwards compatability.

At that point the company will probably decide to completely drop the template engine and go with another one that may not leave them hanging when they upgrade. If they have to rewrite hundreds of templates they would rather rewrite them for a different template engine that may not make a change that causes most of their templates to fail instead of a template engine that may cause them to rewrite things again in the future.

For me it is going to be a pain in the butt to have to go back through everything and add that one line above to any PHP code in my templates. If there was a configuration option that would allow the same thing then no one is hurt and everyone is happy.

You have to think of the people who are using the product.
Back to top
View user's profile Send private message
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Wed Jun 25, 2003 11:15 pm    Post subject: Reply with quote

@panama jack:

tru dat.

Still, most large projects I have worked on choose a platform and stick to it until the bitter end. They don't upgrade--they patch bugs and that's it. Functionality is designed based on what the platform offers at the time it was chosen. The point is that a project doesn't pick language A 1.0 because they think that they will one day want to use A 2.0. (Think about your car, you don't upgrade the engine everytime the manufacturer upgrades the engine design).

So, once the choice is made for a given project, hardly anyone ever wants to change it precisely for the reasons you mentioned. There is an axiom about not trying to upgrade a "classic" computer (one that is more than a couple of years old) because it is typically more painful -- and expensive -- than just buying a new box. A well engineered software project is the same way--if you want it to always meet your expectations, you don't go changing it with the seasons--you run it as it was designed. That's why there are still 30 year old (and more) computers and programs still running today on the same equipment that they were put into service with.

So, while I agree that BC is very important, I do not think it is the end all that you make it out to be. Further, I think you are once again unfairly characterizing Smarty's development -- I know for a fact that the Smarty developers do just about everything they can to maintain backwards compatability or at least minimize change impact. When BC changes are made, they are typically well discussed on the smarty-dev mailing list (and tested in CVS) prior to being commited to the next release version.

Still, as a product evolves it is natural that the feature-set will change. Perhaps your best choice is not to do anything to the site--leave it at 2.3.1. For your next project, consider switching to the next available version and take into consideration the newer paradigm. I realize that from where you are sitting it probably seems like an idiotic decision made by uncaring people. But as Monte pointed out, it was done to speed Smarty up for the widest variety of users, though it obviously is causing pain to a smaller minority of users. There are good and bad design decisions on every project -- as a developer, I am sure that you appreciate that BC is just one issue (albeit very important) to be considered when changes are made.

Perhaps this is a case where BC shouldn't be broken (though I disagree). The flip side is that newer releases typically offer either improved features or faster performance (though RARELY both) so when considering what you are losing, also consider what you are gaining -- and make that calculation! Do not upgrade if you are taking a net step backwards!! This is especially true for libraries which you actually integrate into your application (like Smarty).

That's my 2c Smile

EDIT: note--upgrades typically IMPLY a sub-project to co-ordinate changes that the upgrade requires. IE. no one actually BELIEVES that upgrades are transparent even if the vendor insists they are. One of my clients is a large trading house in Toronto. Things can't EVER be down. There is no rush to upgrade software (and hardware) simply because new versions become available. In many ways, an upgrade is trickier than the initial project deployment!
Back to top
View user's profile Send private message
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    Smarty Forum Index -> General All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP