CodeIgniter Forums
Better Template Engine - Printable Version

+- CodeIgniter Forums (https://forum.codeigniter.com)
+-- Forum: Development (https://forum.codeigniter.com/forum-6.html)
+--- Forum: CodeIgniter 3.x (https://forum.codeigniter.com/forum-17.html)
+--- Thread: Better Template Engine (/thread-1362.html)



Better Template Engine - Tux - 03-03-2015

Request for better template engine. Something like;
http://docs.phalconphp.com/en/latest/reference/volt.html


RE: Better Template Engine - tapan.thapa - 03-03-2015

You can anytime go and use Smarty. (http://www.smarty.net/)

No one is stopping us.. Cool


RE: Better Template Engine - tapan.thapa - 03-03-2015

(03-03-2015, 12:58 AM)tapan.thapa Wrote: You can anytime go and use Smarty. (http://www.smarty.net/)

No one is stopping us.. Cool

One more info:

CI is having a template class (parser) since starting but i don't know why CI community is not upgrading parser class with feature set required by many developers.

http://www.codeigniter.com/userguide3/libraries/parser.html


RE: Better Template Engine - spjonez - 03-03-2015

It's hard to please everyone with so many parser libraries already out there. Client side templating is where it's at IMO!


RE: Better Template Engine - sv3tli0 - 03-04-2015

Whats the point to use {variable} to generate
PHP Code:
<?php echo $variable?>
?
Are you PHP devs or Smarty/Twig devs ? There is nothing cleaner than, a clean PHP. Smile


RE: Better Template Engine - Maximw - 03-04-2015

(03-04-2015, 02:46 AM)sv3tli0 Wrote: Whats the point to use {variable} to generate
PHP Code:
<?php echo $variable?>
?
Are you PHP devs or Smarty/Twig devs ? There is nothing cleaner than, a clean PHP. Smile

Yes! PHP is the best template engine in PHP-ecosystem.


RE: Better Template Engine - ciadmin - 03-04-2015

Some of "us" are cowboys, working on our own, and pure PHP might be preferable.

Others of us, however, work in multi-disciplinary teams, where "we" do the coding; a graphic designer does images, styling and layout; and a "web developer" does the HTML and Javascript. In such an environment, having something like
<p>Hello {firstname}! Thank you for your purchase of {quantity} tickets for {event}</p>
is preferable to non-programmers than something like
<p>Hello <?php echo $firstname ?>! Thank you for your purchase of <?php echo $order->total_quantity($ticket_number) ?> tickets for <?php echo $event?></p>

Everyone has different needs, and there is no single solution for all.

FWIW, one of my "golden rules" is "no PHP in a view" ... I feel it results in a better "separation of concern", which is one of the reasons to use an MVC design pattern.


RE: Better Template Engine - mwhitney - 03-05-2015

Honestly, if someone calls themself a "web developer" and can't handle a little inline PHP, they need a new job title. This is why we have "web designers" and "front-end developers", to cover the middle ground between "web developer" and "graphic designer" (and I would say that assuming a "graphic designer" can do styling and layout for a website is dangerous ground). Additionally, it takes almost as much time to explain to some people what {firstname} means in the middle of the HTML as <?php echo $firstname; ?> (never mind some of the more complicated features of some templating tools).

Personally, I just do my best to limit the PHP used in a view to the simplest possible PHP, usually equating to what's commonly supported in templating languages (echo, foreach, if/else). When I run across a view which is overly complicated for some reason, I try to refactor it by first moving as much of the PHP as possible to the top (our web designer will skip any block of PHP at the top unless the text that needs to change turns out to be in a variable instead of being directly in the view), then moving it to the controller (and, eventually, off to wherever it really belongs).

So far, it has been far more difficult for our web designer to access and use our version control repository and determine where to find the view for a given page (or portion of a page) than to handle our use of PHP in views. I think this may be more universal than most people believe.

That said, it's certainly understandable in some situations that a templating language would be preferable for views over raw PHP. I also find that templating tools act as a reinforcement of the otherwise self-enforced limitation on the use of PHP in views, which can make them very useful in some environments.

As for the original question/request, CI can't provide the perfect solution for everyone. In most cases, it does its best to supply the basic tools for the job, then gets out of the way. It's fairly easy to implement any number of templating tools in CI, so there has been little reason for the CI community to extend the functionality of the basic parser which is included by default. Most people who prefer to use templating tools already have a library they prefer and they can use that library with CI (unless it happens to have been written for some back-end language other than PHP).