Why smarty was never used in development of q2a to seperate presentation from biz logic?

Question

Working with PHP scripts would be way better if smatry (http://www.smarty.net/why_use) were used in q2a source.

ANy idea why?

Answer 1

My opinion:

Smarty was used well in old days. However, it became rarely used recently. Smarty has many advantages, but there are many faults at the same time, too. One of the advantages for me is cache feature. However, this can substitute in PHP. In addition, debug of smarty is inconvenient. It makes Smarty important to separate design and logic, but, except some exceptions, design and logic are isolated in Q2A. Therefore the further separation is unnecessary. The data structure of Q2A is very complicated unlike blog and general site. It will become really mysterious thing when we make template of Q2A in Smarty.

Comments

Thank you for your input Sama

Answer 2

I've asked that months ago. Here you can see a somehow official answer (comment, actually): http://www.question2answer.org/qa/31514?show=31529#a31529

As of today, turning to any template engine would be a lot of work and would require a lot of refactorings. Not to mention it will most likely mean rewriting most plugins and themes. I've also learned backwards compatibility is a very strong argument when it comes to making architectural decisions.

Answer 3

You seem to be under the impression that presentation and business logic are not separate in Q2A, but that's incorrect. Nearly all the presentation side is separated into the theme class. There are a few exceptions with HTML being created in other places but I'll be trying to reduce these in later versions (in fact I already did some for 1.7). But there is no "logic" in the theme class, just standard variables/ifs/foreach.

Smarty is quite an outdated templating engine so if Q2A were to use one it would be something more modern like Twig. However, using any templating engine in Q2A is pretty difficult since Q2A theming is very flexible.

In themes you can override very small parts of the output. Furthermore, each part may appear on multiple pages (e.g. the basic style for a question) which would mean a lot of repetition across page templates. I've discussed this with Gideon and we haven't figured out a good way to handle that besides having dozens of individual files with tiny snippets of HTML in them.