Hi folks,
we’re thinking about using OXID as our shop-system, but it has a fat, purulent disease: Smarty! :S
Is there a solution for OXID without smarty? We’re thinking about to cut it out of OXID by ourselves, but before doing this, we thought: “Maybe someone else has done it before!?”.
Thanks and greetings,
Andreas Hofmann!
OXID together with Smarty works very well. I don`t know any reason why oxid should not use Smarty as Template Engine.
We’re thinking about to cut it out of OXID by ourselves
Then you have to change nearly all oxid files…
[QUOTE=Michael Fritsch;25370]Oxid together with Smarty works very well. I don`t know any reason why oxid should not use Smarty as Template Engine.[/QUOTE]
Because it’s an overhead you don’t need! You’re putting another layer onto the thing… why do i have to write [{foreach key=“foo”… }] instead of yusing just php in the templates!? You cannot be free to do all stuff you want to do, you’re always bound to the smarty-syntax and which variables/ressources you can access with smarty. Also I can’t do sth like this in smarty:
[{ $foo->bla()->blub() }] smarty complains “wrong syntax, foobar”. I have to do an [{ assign }] first and then call blub() on this assign var. In php it would just work! And using this whole overhead costs ressourcetime for sure!
Every current framework uses php in the templates. because it’s fast, the same language and powerfull as hell! 
One of the core-ideas behind templatelanguages, is that the designer doesn’t have to learn php. But hey, he has to learn how all the controlstructures work in smarty which are all a mask for the same thing in php. So why can’t he learn how a foreach in php works, which is less to write!
You know what I’m tring to say
[QUOTE=Michael Fritsch;25370]Then you have to change nearly all oxid files…[/QUOTE]
That’s the reason why I’m asking, maybe someone has done it before or someone can say that it’s hard or easy! 
Well, apparently you are seriously asking for trouble…
I would suggets Magento for you then, you get all the crap you’re looking for there.
Smarty is one thing which makes OXID shine…
Who cares for somme Milliseconds on top???
[QUOTE=avenger;25383]Well, apparently you are seriously asking for trouble…
I would suggets Magento for you then, you get all the crap you’re looking for there.
Smarty is one thing which makes OXID shine…
Who cares for somme Milliseconds on top???[/QUOTE]
Seriously, that’sa silly answer! Oxid provides the best structure and best features in my opinion! And it’s great to customize! And I’m asking for a customization and you say “go away!”. That’s really silly!
And the key thing is not the “some milliseconds”, it’s that I’m (or our web-designer) is free to do what he wants, and not what smarty provides with it stupid syntax!
Btw: I’ve managed to kill smarty with only a few lines of code (Overload of the oxShopControl::_process()-method!
Works great
i don’t like smarty either. i like template engines which work with pure php and not with a pseudo language on top. The nice things about smarty are the filters / functions etc, but you can realize such functionality with pure php, too.
could you post the lines of code?
[QUOTE=andreas.hofmann;25384]
Btw: I’ve managed to kill smarty with only a few lines of code (Overload of the oxShopControl::_process()-method!
[/QUOTE]
Pls let us know what kind of performance gain you get in the end.
Thanks,
Achim
@csimon & oxal:
Cutting out Smarty is quiet easy:
The oxShopControl-class/view holds THE smarty-object and finally renders the “controller/action” and then the template using smarty.
The easiest way (but not the best) is to create a module overloading this class. Copy the _process()-method to this overloader, kick the oSmarty-var away, do an extract() instead of the smarty->assign_by_ref() and do an include instead of the smarty->fetch()! That’s it! Now you’re using just php!
BUT: it’s not finished! I’m now working on an automatic mapper of the smarty-functions! We don’t need all this stuff, for example this silly default()-method! Why not using the ternary operator?? But we need stuff like the oxid_multilang-function and other oxid-functions.
I’m working on it and I talked to an OXID Community Guide, who asked me to provide this code. And l will provide the code, but it could take a while (End of this week, beginning next week), because the final decison which shop-system we will use was not made until yet, but we will decide it this week. Then I can develop with full speed on the “KillSmarty”-Module
Thanks for your interest and greetings from cologne,
Andreas!
Hi Andreas
i think you want to extend/make module of core/oxUtilsView.php, there are all smarty related functions and methods.
My suggestion would be: create smarty wrapper and use oxUtilsView.php to manipulate the data coming from Oxid
Hi again
I just want to give an update:
I managed to “kill” Smarty, like I said. I’ve also done a Utils-class that automatically wraps all the custom-smarty-functions/modifiers/etc…
The class does not disable smarty completely, it just enables you to decide, if you ant to render php or smarty. Killing smarty completely is not recommended, because the admin works with smarty as well
But you can disable it completly for your whole frontend, by just creating .php files instead of .tpl files.
I will test it a little bit more and think that I can give you a first version on Friday. My first test was to rewrite the startpage template: Success!Just pure php Delicious
Greetings from cologne,
Andreas Hofmann!
Hi,
there is an option in admin -> core settings -> system -> other settings -> How to handle PHP code embedded in templates. Turning it to “execute PHP code”, isn’t it the same what you did?
Regards
[QUOTE=andreas.hofmann;25455]Hi again
I just want to give an update:
I managed to “kill” Smarty, like I said. I’ve also done a Utils-class that automatically wraps all the custom-smarty-functions/modifiers/etc…
The class does not disable smarty completely, it just enables you to decide, if you ant to render php or smarty. Killing smarty completely is not recommended, because the admin works with smarty as well
But you can disable it completly for your whole frontend, by just creating .php files instead of .tpl files.
I will test it a little bit more and think that I can give you a first version on Friday. My first test was to rewrite the startpage template: Success!Just pure php Delicious
Greetings from cologne,
Andreas Hofmann![/QUOTE]
Could you show your new “start”-Template, just to see the difference?
On thing to keep in mind is, that you are running the risk, to detach yourself very effectively from easy template updates…
These are communicated as “diff”-lists against the previous template version, and I believe it will become a hell of a job to retrofit these in a completely different template structrue.
You sure can handle this, but this is definitely nothing I would recommend to “Joe Shopowner”…
[QUOTE=Marco Steinhaeuser;25468]Hi,
there is an option in admin -> core settings -> system -> other settings -> How to handle PHP code embedded in templates. Turning it to “execute PHP code”, isn’t it the same what you did?
Regards[/QUOTE]
No, not really…
This option only defines, that you can use “<?php” and “?>” to designate PHP-snippets within Smarty template files, instead of having to use “[{php}]” and “[{/php}]”.
But still Smarty does the complete rendering.
[QUOTE=Marco Steinhaeuser;25468]Hi,
there is an option in admin -> core settings -> system -> other settings -> How to handle PHP code embedded in templates. Turning it to “execute PHP code”, isn’t it the same what you did?
Regards[/QUOTE]
Like avenger said, it’s not the same. The first thing is, that smarty is doing the whole rendering and the second is, that all the vars, assigned to smarty are nnot in the php symbol table, so you don’t have access to it, also there is no $smarty var. So you can do nearly nothing
[QUOTE=avenger;25513]Could you show your new “start”-Template, just to see the difference?[/QUOTE]
You mean the code or the result? The result is the same, there is no difference. The only difference is, that it feels faster.
[QUOTE=avenger;25513]On thing to keep in mind is, that you are running the risk, to detach yourself very effectively from easy template updates…
These are communicated as “diff”-lists against the previous template version, and I believe it will become a hell of a job to retrofit these in a completely different template structrue.
You sure can handle this, but this is definitely nothing I would recommend to “Joe Shopowner”…[/QUOTE]
Yeah for sure, that’s right. It’s a hell of a job doing this. It’s the same as conflicted SVN-Files! Hell! Noone wants to do this
And we won’t, because we will have a complete own design, we won’t need the default layout. We will do a bigger thing with OXID. And that’s one of the main reasons to get rid of smarty, because our web designer than don’t have to do this ugly smarty stuff, he can just write easy and fast php.
Currently we are using the framework cakePHP for our platform and there you don’t have any template language! Just php! You get the variables available directly from the controller. And that’s the thing he likes and we programmers like
Currently the conclusion is, that some files I converted are bigger, some are smaller. When I’m finished, I think all files will be smaller, because I will optimize some function calls, I will make them shorter. For example the oxmultilang(). In cakePHP the translate function is __(). I think I will do sth like this.
Greetings from cologne,
Andreas!
Hi,
yes but
We shall consider that - with php templates - more and more people will start building functionality into the templates. Using smarty you must use modules to extend the functionality.
IMO the best way would be kind of a module that switches smarty off so you can work with php templates. But in this case, you really have to know what you are doing.
Do you see my point?
Regards
[QUOTE=Marco Steinhaeuser;25523]Hi,
yes but
We shall consider that - with php templates - more and more people will start building functionality into the templates. Using smarty you must use modules to extend the functionality.[/QUOTE]
Yeah and no. That’s what called a coding guideline Functionality has nothing to to within a view/template. It has to be localted in the controller/module. I’ll kick our webdesigner if he writes mechanic into the view (But he doesn’t ).
It’s just that you have to know, that you don’t have to and that you don’t do it. If someone is doing it in his shop for himself, ok! Why not, it’s his thing! But i think noone of the OXID devs would do that or in project-teams like mine, they all have to know to not doing that!
[QUOTE=Marco Steinhaeuser;25523]IMO the best way would be kind of a module that switches smarty off so you can work with php templates. But in this case, you really have to know what you are doing.
Do you see my point?
Regards[/QUOTE]
I think my module is doing that, what you mean. If you create a .php-template, my module includes this and not renders the smarty-.tpl-file! It’s like switching smarty off
You mean the code or the result? The result is the same, there is no difference. The only difference is, that it feels faster.
I mean the template code in php
Ok, here are two short examples, both files are smaller in filesize than the smarty-ones:
The “dyn/top_account.php”:
<?php if($oxcmp_user->oxuser__oxpassword->value): ?>
<dl class="box account">
<dt id="tm.account.dt">
<a id="test_TopAccMyAccount" rel="nofollow" href="<?= $_->_s($oViewConf->getSslSelfLink() . 'cl=account'); ?>"><?= $_->__('INC_HEADER_MYACCOUNT'); ?></a>
</dt>
<dd id="tm.account.dd" class="dropdown">
<ul id="account_menu" class="menue vertical">
<li><a href="<?= $_->_s($oViewConf->getSslSelfLink() . 'cl=account_password'); ?>" rel="nofollow"><?= $_->__('INC_ACCOUNT_HEADER_PASSWORD'); ?></a></li>
<li><a href="<?= $_->_s($oViewConf->getSslSelfLink() . 'cl=account_user'); ?>" rel="nofollow"><?= $_->__('INC_ACCOUNT_HEADER_ADDRESS'); ?></a></li>
<li><a href="<?= $_->_s($oViewConf->getSelfLink() . 'cl=account_order'); ?>" rel="nofollow"><?= $_->__('INC_ACCOUNT_HEADER_ORDERHISTORY'); ?></a></li>
<li><a href="<?= $_->_s($oViewConf->getSelfLink() . 'cl=account_noticelist'); ?>" rel="nofollow"><?= $_->__('INC_HEADER_NOTICELIST'); ?></a></li>
<li><a href="<?= $_->_s($oViewConf->getSelfLink() . 'cl=account_wishlist'); ?>" rel="nofollow"><?= $_->__('INC_HEADER_WISHLIST'); ?></a></li>
<li><a href="<?= $_->_s($oViewConf->getSelfLink() . 'cl=compare'); ?>" rel="nofollow"><?= $_->__('INC_ACCOUNT_HEADER_MYPRODUCTCOMPARISON'); ?></a></li>
<li><a href="<?= $_->_s($oViewConf->getSelfLink() . 'cl=account_recommlist'); ?>" rel="nofollow"><?= $_->__('INC_ACCOUNT_HEADER_MYRECOMMLIST'); ?></a></li>
<li><a href="<?= $oViewConf->getLogoutLink(); ?>" rel="nofollow"><?= $_->__('INC_ACCOUNT_HEADER_LOGOUT'); ?></a></li>
</ul>
</dd>
<dd>
<?= $_->__('INC_CMP_LOGIN_RIGHT_LOGGEDINAS'); ?><br>
<b><?= "{$oxcmp_user->oxuser__oxfname->value} {$oxcmp_user->oxuser__oxlname->value}"; ?></b><br>
<span class="btn"><a id="test_TopAccLogout" href="<?= $oViewConf->getLogoutLink(); ?>" rel="nofollow"><?= $_->__('INC_HEADER_LOGOUT'); ?></a></span>
</dd>
</dl>
<?php $_->oxscript(array('add' => "oxid.topnav('tm.account.dt','tm.account.dd');")); ?>
<?php endif; ?>
And the “dyn/top_basket.php”:
<?php if($oxcmp_basket->getContents()): ?>
<?php $currency = $oView->getActCurrency(); ?>
<dl class="box basket">
<dt id="tm.basket.dt">
<a id="test_TopBasketHeader" rel="nofollow" href="<?= $_->_s($oViewConf->getBasketLink()); ?>"><?= $_->__('INC_HEADER_CART'); ?></a>
</dt>
<dd id="tm.basket.dd" class="dropdown">
<ul id="basket_menu" class="menue vertical">
<li><a href="<?= $_->_s($oViewConf->getSslSelfLink() . 'cl=basket'); ?>" rel="nofollow"><?= $_->__('INC_ACCOUNT_HEADER_TOBASKET'); ?></a></li>
<?php if($oxcmp_user->oxuser__oxpassword->value && $oView->isLowOrderPrice()): ?>
<li><a href="<?= $_->_s($oViewConf->getSslSelfLink() . 'cl=payment'); ?>" rel="nofollow"><?= $_->__('INC_ACCOUNT_HEADER_TOPAYMENT'); ?></a></li>
<?php endif; ?>
</ul>
</dd>
<dd>
<table summary="<?= $_->__('INC_HEADER_CART'); ?>">
<tr>
<th><?= $_->__('INC_CMP_BASKET_PRODUCT'); ?></th>
<td id="test_TopBasketProducts"><?= $oxcmp_basket->getProductsCount(); ?></td>
</tr>
<tr>
<th><?= $_->__('INC_CMP_BASKET_QUANTITY'); ?></th>
<td id="test_TopBasketItems"><?= $oxcmp_basket->getItemsCount(); ?></td>
</tr>
<?php if($oxcmp_basket->getFDeliveryCosts()): ?>
<tr>
<th><?= $_->__('INC_CMP_BASKET_SHIPPING'); ?></th>
<td id="test_TopBasketShipping"><?= $oxcmp_basket->getFDeliveryCosts() . " {$currency->sign}"; ?></td>
</tr>
<?php endif; ?>
<tr>
<th><?= $_->__('INC_CMP_BASKET_TOTALPRODUCTS'); ?></th>
<td id="test_TopBasketTotal"><?= $oxcmp_basket->getFProductsPrice() . " {$currency->sign}"; ?></td>
</tr>
</table>
</dd>
</dl>
<?php $_->oxscript(array('add' => "oxid.topnav('tm.basket.dt','tm.basket.dd');")); ?>
<?php endif; ?>
The advantage is visible:
Ugly for sure is the <?php and ?> but you can shorten it to <?= which means <?php echo or just do more in php, so you don’t still open and close the php-brakets!
Ok, today is the worst day of the month… maybe of the year…
The CTO said to you last week “I really believe that we will do Oxid!”. Today he said “we won’t do Oxid! We take this Typo3-Custommade thing. I don’t like typo3 either, but we take this!”
So I won’t finish my "KillSmarty"Module, but it works good already. It’s for sure not complete, but it works.
I will provide it to the community tomorrow, together with another module I’ve written to expand a Deliveryset with an tracking-URL.
That’s live, bye OXID 
[QUOTE=andreas.hofmann;25672]Ok, today is the worst day of the month… maybe of the year…
The CTO said to you last week “I really believe that we will do Oxid!”. Today he said “we won’t do Oxid! We take this Typo3-Custommade thing. I don’t like typo3 either, but we take this!”
So I won’t finish my "KillSmarty"Module, but it works good already. It’s for sure not complete, but it works.
I will provide it to the community tomorrow, together with another module I’ve written to expand a Deliveryset with an tracking-URL.
That’s live, bye OXID :([/QUOTE]
That’s what I call thorough decision-making… 
After long analysis of hard evidence and facts, there was finally a gut decision for Typo3 :eek:
Applause for a showcase in making management decisions!
A fine candidate for “CTO of the year”…