Welcome Guest, Not a member yet? Register   Sign In
Opinion: Template Engine Integration RIP?
#1

There has been lots of chatter about templating engines, and their support/integration/assimilation into CI4.
I have taken a look at all the ones suggested/insistedon/beggedfor, and a few more: div, dwoo, foil, haanga, latte, lex, plates, scurvy, smarty, ste, tbs & twig.
I have come to the conclusion that each one of these has its own philosophy/dependencies/assumptions/"api", and that is it not practical to have any sort of tight integration with any of them, nor do we want to undertake to support such a dog's breakfast!

Some of these engines look very powerful, some are bloated, some are not ready for prime time - but they are all valid tools that a developer might want to use in a webapp project, and it would be awesome to have an elegant solution for exploiting them.

One of the community members pointed out FuelPHP, with adapters to a number of them. I took a look at https://github.com/fuel/parser, which looks like a good solution for them, with some interesting takeaways for CI. Their Parser is a bit clunky, with configuration for all the engines in one class, and each adapter extends Fuel's View. The smarty & twig adapters have a Fuel extension as well, providing a number of Fuel-like functions for use inside template files. Bottom line: although a separate repo, this does not look like it is meant to be plugged into an app using a different framework.

I would call Fuel's template engine "integration" loosely coupled, in that it primarily binds an engine to a View object intended to process files passed as method parameters. ANy advanced template engine capabilities have to be incorporated into your template files/classes on your own, and those are not "known" to any of the other Fuel components.

This looks like a possible way to accommodate different engines, but is way out-of-scope for CI4's phase 2 and possibly phase 3. Further, it will only happen if the community steps up, i.e. developers familar with an engine would have to build and support an adapter for that engine.

I suggest that this issue/featurerequest/demand be put to bed for now, i.e. deferred until we have a solid base for CI4. We will have a better feel then for how to architect adapters for all the kinds of things the community would like to see integrated.
James Parry
Project Lead
Reply
#2

I agree with what you are saying JP, The only thing I would add maybe now to CI4 would be a switch from the CI4 template parser to one of the other ones, where as the CI4 template parser would be the default one.
What did you Try? What did you Get? What did you Expect?

Joined CodeIgniter Community 2009.  ( Skype: insitfx )
Reply
#3

jlp, if we are going to be loading a "parser" as a service in CI4 using a standard class name like CI3's "parser" for that service is great but, how will multiple 3rd party developers know which parser engine is being used and how can we use multiple at the same time?

1. I use pyrocms/lex for my email template "views"
2. I use 3rd party Library "foobar" which wants me to use template library "barfoo" because it's views are in "barfoo" format
3. I use 3rd party Library "aaaa" which wants me to use template library "zzzz" because it's views are in "zzzz" format
4. I use "handlebars" for my code because of course my views are in handlebars format.

Of course in my own code I can load the template library pyrocms/lex & handlebars directly and call them as needed.
Something like this:
$this->lex_parser->parse('email_template', $data);
- and -
$this->handlebars_parser->parse('blog_template', $data);

If 3rd party code assume you are using there chosen "parser" how will they work together?
I assume they will both just use.
$this->parser->parse('some_template', $data);
but this won't work for templates / plugins in different formats.

Maybe register template file extensions and/or folders as certain formats?

I hope this is clear?

DMyers
Reply
#4

(07-20-2016, 06:14 AM)dmyers Wrote: jlp, if we are going to be loading a "parser" as a service in CI4 using a standard class name like CI3's "parser" for that service is great but, how will multiple 3rd party developers know which parser engine is being used and how can we use multiple at the same time?

1. I use pyrocms/lex for my email template "views"
2. I use 3rd party Library "foobar" which wants me to use template library "barfoo" because it's views are in "barfoo" format
3. I use 3rd party Library "aaaa" which wants me to use template library "zzzz" because it's views are in "zzzz" format
4. I use "handlebars" for my code because of course my views are in handlebars format.

Of course in my own code I can load the template library pyrocms/lex & handlebars directly and call them as needed.
Something like this:
$this->lex_parser->parse('email_template', $data);
- and -
$this->handlebars_parser->parse('blog_template', $data);

If 3rd party code assume you are using there chosen "parser" how will they work together?
I assume they will both just use.
$this->parser->parse('some_template', $data);
but this won't work for templates / plugins in different formats.

Maybe register template file extensions and/or folders as certain formats?

I hope this is clear?

DMyers

At the moment, CI4 has you specify a Renderer in the Config\Services::renderer(), which assumes that a single Renderer will be used.
Your usecases are valid, and the reason I wanted to defer dealing with multiple engines until after out "basics" are in place. This Renderer would be the one used by the global view() function, but that doesn't mean you can't use other view generators elsewhere.

In the meantime, an external packages can be as just that, eg

[code]$myHandlebarPresenter = new \Something\Cool\TemplateEngine();
$myHandleBarPresenter->parseOrWhatever('some_template',$data);['code]

If a third party package uses a template engine for any of its job, that will continue to work - I don't see anything in CI4 that would prevent that. I see that as a good use of composer.


My plan for our ClassFormerlyKnownAsTemplateParser is to have it in the CodeIgniter\Views namespace, as a slightly beefier alternative to the "regular" view, and not as *any* sort of template engine.

And yes, when we get to it, something like registering template engines or file extensions or formats etc etc, would make powerful sense. I am just trying to keep things as simple as possible in the early stages Smile  I'm sure this will get clearer as development proceeds!
Reply
#5

There are many template engines, but as good choices I would recommend those that have at least PHP and JavaScript implementations. A possibility a same template to be rendered on the server side and on the browser side is likely to be more demanded in the future, I think. I noticed at least one promising JavaScript framework that uses Handlebars for example. Good choice, DMyers. Maybe it would be a good idea the "custom" CodeIgniter parser to be replaced by Handlebars.

So, with this additional condition (PHP + JavaScript) the set of interesting engines narrows:

Twig - it has JavaScript implementations, maybe not mature enough, but this is a matter of time.
Handlebars
Mustache - there are native engines, also the syntax is likely possible to be handled by Handelbars engine that is set in compatibility mode.

If there are "official" adapters for these three engines that would be enough work done by the CI team. Other engines would be kind of exotic.
Reply
#6

(07-20-2016, 10:10 AM)ivantcholakov Wrote: ...
If there are "official" adapters for these three engines that would be enough work done by the CI team. Other engines would be kind of exotic.

Good points. We can start with these, when the time is ready.
Reply
#7

ciadmin, A "standard" CI library built in sounds great. As it will be the defaco. This way any "additional" engines will need to follow guidelines to be used (just like today).
I just didn't want to see somebody expect parser "foobar" to be the defaco and then everything not using that breaks. Like in there instructions "just add this to make foobar your default parser and your views will work". Instead it could be (just a example of course) "just add ".lex" => 'pyrocms/lex' to your view render config file and your views will work"

Just a FYI https://github.com/zordius/lightncandy is the handlebars library I currently use and as ivantcholakov said one of the main reasons I chose it was because the client and server side "views" can use the same syntax. Which in turn is one less thing for our designers to learn.

DMyers
Reply
#8

(07-20-2016, 01:28 PM)dmyers Wrote: Just a FYI https://github.com/zordius/lightncandy is the handlebars library I currently use and as ivantcholakov said one of the main reasons I chose it was because the client and server side "views" can use the same syntax. Which in turn is one less thing for our designers to learn.

DMyers

I will check this out, thanks Smile
Reply
#9

In the past I have suggested that settling on and including a template engine of some description by default would be a good idea, but having read some of the comments about complexities and issues that arise I think I have changed my mind. So I think you are completely right to suggest just putting this entire thing to one side and forgetting about it for now.

Best wishes,

Paul.
Reply




Theme © iAndrew 2016 - Forum software by © MyBB