OXID without Smarty?

hehe, yeah…

But for his defense, I have to say that there are good reasons for it. If I would give the Pro’s for each system a weight, I think OXID has 1gram more! :wink: PLUS it’s the better syste for the future, I think! The Reasons for typo3 are heavy, but OXID is reeeaaalllyyy the better system, for sure. The CTO knows that, too. But there are criterias for using this typo3 system (I can’t explain them here).

If I ever have to do a shop in the future, I know what to take :wink: Maybe I will continue building OXID stuff, lets see…

Best greetings,

Andreas!

Hi,

[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]

What a bummer! Hope to see you in a while with another project. :wink:

Regards

Und die Hüte von Avenger und Andreas hätten so gut zusammengepasst. :frowning:

So, like I said, I’ve registered “KillSmarty” and my “PackageTracker” as projects at https://dev.oxidforge.org.

Hope you have fun using or developing them! I try to give support as good as I can!

KIllSmarty:
https://dev.oxidforge.org/projects/killsmarty
PackageTracker:
https://dev.oxidforge.org/projects/packagetracker

Best greetings from cologne,

Andreas!

Well done, mate!

just wanted to totally agree with andreas.hofmann
smarty is an abomination, which was not good 10 years ago, and if one ever has the chance to avoid it, one should.

Checking out the kill smarty module now…

[QUOTE=soup;87225]just wanted to totally agree with andreas.hofmann
smarty is an abomination, which was not good 10 years ago, and if one ever has the chance to avoid it, one should.

Checking out the kill smarty module now…[/QUOTE]
I totally disagree…

Smarty is a major asset for successful shop Software.

Take xtCommerce + forks, OXID, Shopware…

Especially the new Smarty 3 features like block inheritance allows for very flexible templating.

In contrast, Magento’s templating is just a pain in the ass…

well i still disagree from the point of view, as a developer its always a 1000 times easier to program in the language you know
ie php + html + css

i don’t need the bloat / parsing rubbish from smarty
why should i have to learn / know a new format / way of writing a for or foreach loop for example
its simple in basic php. !
so is echoing out variables

and the argument that you don’t need to know php…well true but you still need to know or learn smarty

i think the idea from andreas was brilliant, ie you have the choice to use smarty if you want, or php

and xt + the forks are all based on 10 year old software, thats the point, when smarty was “in”

[QUOTE=soup;87269]and xt + the forks are all based on 10 year old software, thats the point, when smarty was “in”[/QUOTE]Shopware ist the most “stat of the art” shop-software around, and yes, they use Smarty…

And you have to consider one thing: OXID will document template changes based on the existing templates, and it is hard enough to integrate these in your own (modified) Smarty-based templates.

I don’t want to even think about doing that with a totally differnt template technology.

Anyway - we never will find a conclusion satisfying all people. So In my opinion it is not needed to blame one solution against the other as long as it is possible to use what you are prefering personally.

not meant as blame…thats exactly why i said i though andreas module was great, because it gives you the choice

you can use smarty or not, for each template as you wish
ie the best of both worlds, theoretically everyone would be happy with that
if you want smarty, you’ve got it and don’t need to change anything
BUT you can create your own php templates

which btw somewhat obviously would be custom templates and no i would not expect them to be updated by oxid !

oh and a another btw - i definitely find this, a lot easier to read and less cryptic…
<?php if ($oViewConf->getFbAppId()) {
if ($oViewConf->getActiveClassName() == ‘details’ ) { ?>
<meta property=“og:title” content="<?=($_titleprefix) ? $_titleprefix : ‘’;?><?=($_title) ? strip_tags($_titleprefix) : ‘’;?><?=($_titlesuffix) ? $titlepagesuffix : ‘’;?>"
<? }
}
?>
than this
[{if $oViewConf->getFbAppId()}]
[{if $oViewConf->getActiveClassName() == ‘details’ }]
<meta property=“og:title” content="[{ $_titleprefix }][{if $title&& $_titleprefix }] | [{/if}][{$title|strip_tags}][{if $_titlesuffix}] | [{$_titlesuffix}][{/if}][{if $titlepagesuffix}] | [{$titlepagesuffix}][{/if}]">
[{/if}]
[{/if}]

but thats just me then
…just the fact that instead of end the if with } i have 5 characters… [{/if}] ?

oh and the old short tags argument won’t work in the future either.
Short tags in future PHP versions are on by default

I just came across this thread and that’s one of the most interesting discussions ever.

From my experience smarty is a headache for the mayority of users and they ask what’s that? There are surely some good pros but as many cons or even more like here: http://shkhan.wordpress.com/2009/01/19/scope-into-smarty-template/

Since php allows to achieve same results as smarty in the end, it’s most likely not a must have. It should rather be dropped - at least to give many more people straight access to oxid frontend code and to grow Oxid accordingly.

A good question came up recently: “Hat Oxid Zukunft ?”.
Surely - but Oxid should seriously consider this issue in Version 6, while cleaning up remaining old tables, inline styles and user requests as well.

Hey mates,

indeed: it is definitely an interesting thread but has nothing to do with OXID’s future, has it?

My personal opinion: presently, Smarty is one of the most powerful template engines - just HTML and a bit of view functionality, even comes up with a caching mechanism. From the OXID eShop admin, you can even decide if PHP functionality shall be executed.

If you want to get rid of it - no probs - join this project:
https://projects.oxidforge.org/project/admin/?group_id=19

Most interesting would be the question to have a general template layer, so to say - connect any other template engine (even a pure PHP one) to the shop :wink:

Am not trying to promise or to evoke a version number for this request :wink:

Cheers

[QUOTE=soup;87274]
but thats just me then
…just the fact that instead of end the if with } i have 5 characters… [{/if}] ?

oh and the old short tags argument won’t work in the future either.
Short tags in future PHP versions are on by default[/QUOTE]
Well i use short tags and php-templates in my own apps, but i think i like the fact that oxid uses smarty. In your example, you would have to write not just } in most cases but <?php } ?>, that is more characters than smarty. :wink:
Short tags have always been on by default to my knowledge, the change in future versions is you can use <?= instead of <?php echo without having short tags on, which makes templating a lot easier, but only from php 5.4 on. So in the meantime you can’t rely on shorttags on, and will have to use <?php echo.

[QUOTE=leofonic;90660]Well i use short tags and php-templates in my own apps, but i think i like the fact that oxid uses smarty. In your example, you would have to write not just } in most cases but <?php } ?>, that is more characters than smarty. :wink:
Short tags have always been on by default to my knowledge, the change in future versions is you can use <?= instead of <?php echo without having short tags on, which makes templating a lot easier, but only from php 5.4 on. So in the meantime you can’t rely on shorttags on, and will have to use <?php echo.[/QUOTE]

er…no

in my example i use
<? }
}
?>
which is, in total 6 chars
smarty manages the same so
[{/if}]
[{/if}]

which is 14 chars, and to me personally a lot less attractive as code.
Oh and cos oxid does not even use standard smarty tags (why?), the syntax highlighting of most editors, does not work without modification.
Also i know of no editor where i can match the smarty tags, whereeas the majority of editors have no problems matching brackets.
So when i have a large loop, with lots of subloops, its not fun with smarty trying to match things.

OK i would use:

<?php
	}
}
?>

Which is slightly less characters than smarty but more lines. Better to read in fact. I don’t want to argue how super smarty is, because i think it is not. Even the smallest things are much harder than in php. But in the end, you don’t need most of the stuff in templates as you can move it to the controller. BTW: do you know a good template engine, that uses php templates?

just discovered another thing i hate about smarty !

  • big loops, you comment out one, and smarty throws an error if you comment out the wrong end if…wtf ? - php of course just falls through, it just wants to end ifs

       [{/if}]
    

    [{/if}]
    [{/if}]

Ho have experience migrating Smarty untestable spaghetti code (PHP/HTML/CSS/JS/Smarty all-in-one file) to client side templates using Knockout?