Welcome Guest, Not a member yet? Register   Sign In
Poll: Improvement for Template Parser Class
You do not have permission to vote in this poll.
Yes!
68.75%
11 68.75%
No!
31.25%
5 31.25%
Total 16 vote(s) 100%
* You voted for this item. [Show Results]

Template Parser - class expansion
#1

Hello! As developers look at CodeIgniter is to expand in the future Template Parser Class and add new features?
Template Parser Class now allows you to use the following (Example):

Code:
{name}
- displays the name.

Code:
<ul>
{menu}
<li><a href="/{url}">{name}</a></li>
{/menu}
</ul>

- allow the use of cycle.

Very useful would be the use of conditions. Example:


Code:
{if is_target = 1} Hello world! {/if}

Code:
{if is_target = 1}
Hello world!
{else}
Goodbye world!
{/if}

and etc.

Will this functionality useful for you?
Reply
#2

@condor

There is another old idea proposed for CI3, according to which an external advanced template parser could be used through a driver.

In future terms for CI4, a service locator and adapters for parsers could be created (lately I see that DI has been scrapped). A possibility of using Twig and Mustache parsers is interesting for me.

The CodeIgniter default parser is quite simple now, yes. But I don't see perspective for its syntax expansion, there are better parsers already.

I think, for CodeIgniter parser an improvement that could be implemented is enforced HTML escaping by default with syntax for turning it off on selected places at will.
Reply
#3

http://fabien.potencier.org/templating-e...n-php.html - In conclusion, enable output escaping by default.
Reply
#4

(02-14-2016, 03:53 PM)ivantcholakov Wrote: @condor

There is another old idea proposed for CI3, according to which an external advanced template parser could be used through a driver.

In future terms for CI4, a service locator and adapters for parsers could be created (lately I see that DI has been scrapped). A possibility of using Twig and Mustache parsers is interesting for me.

Quick note to fend off haters - Dependency Injection has NOT been scrapped in CI4, it's used everywhere. A DI CONTAINER has been scrapped and replaced by something more like a factory. It does 95% of the job a container does with a LOT less complexity, makes debugging easier, etc.

(02-14-2016, 03:53 PM)ivantcholakov Wrote: The CodeIgniter default parser is quite simple now, yes. But I don't see perspective for its syntax expansion, there are better parsers already.

I think, for CodeIgniter parser an improvement that could be implemented is enforced HTML escaping by default with syntax for turning it off on selected places at will.

The plan is, I believe, to make it simple to integrate existing template engines, like Twig, Plates, etc. Exact implementation details are not decided on, yet. We will still have the Parser. The exact features are unknown but it's unlikely it will grow a whole lot from it is now.

My personal opinion, though, is that I agree with you. At the very least it needs the ability to do an IF/ELSE flow. I find it close to useless without that. Ideally, it would have the ability to create custom tags, but not included many additional ones out of the box. I don't know where it will end up, though, when all things are said and done.
Reply
#5

(02-14-2016, 03:57 PM)ivantcholakov Wrote: http://fabien.potencier.org/templating-e...n-php.html - In conclusion, enable output escaping by default.

Just to balance the auto-escape argument out:

http://blog.astrumfutura.com/2012/06/aut...pting-xss/

Though I probably shouldn't have posted that since it just will likely bring up more discussion that's likely to subvert the thread. If it does, we'll just split it into it's own thread I guess. The nice thing is, though, no matter which side of the fence you're on (auto-escape or not), you'll be able to do it with CI4. We provide the Zend Escaper (the best one that we know of) so you can manually escape the data. We also have Content Secure Policy baked in (see the above article). And, since you'll be able to use your favorite template engine that does automatic escaping (as well as a number of other goodies), that angle is covered also.
Reply
#6

"And, since you'll be able to use your favorite template engine that does automatic escaping (as well as a number of other goodies), that angle is covered also."

This closes debates. :-)

Straight on the topic: If you have the time for expanding the CodeIgniter parser syntax a little, why not. +1
Reply
#7

(This post was last modified: 02-15-2016, 01:05 AM by sv3tli0.)

What is the difference between those 2 lines

Code:
{if is_target = 1} Hello world! {/if}

<?php if(is_target==1) { ?> Hello world! <?php } ?>

I don't get the point of any parser class which will just make a simple translation from not PHP code to PHP code.. 
Either it should be advance TE or plain PHP.. There is no point of simple parser ..
Best VPS Hosting : Digital Ocean
Reply
#8

On the creation of this topic I pushed the idea that in some cases the use of codes {code} is convenient, especially if the templates will work html coder or a person far from the php code. I agree that use php is much better and it is desirable. Of course, can use Smarty or the Twig, but if it were possible to supplement the capabilities Template Parser and use the template of the box framework. For example, when creating their cms I plan to use to view the folder templates are not * .php, and * .tpl which allow only code {code} instead of pure php. Then pull the necessary data by using these codes. Sorry for my bad english Smile
Reply
#9

(This post was last modified: 02-17-2016, 02:52 PM by ivantcholakov.)

Plates is interesting, I had a look at it. If in the future it exposes a stable API to the developers and a stable API to the other template engines, it could be made multi-syntax, not only for PHP. It could act as a "driver", I hope its authors realize that.
Reply
#10

(This post was last modified: 11-04-2016, 07:52 PM by prezire.)

I believe it's for convenience purposes especially when working with front-ends or non-tech departments. For example, an emailer will be easier for them to create/read:

Code:
Hello {recipient_name}, <br /><br />

These are the items you've bought:
<ul>
 {items}
   <li><a href="{url}">{name}</a></li> <br />
 {/items}
</ul> <br /><br />

Best, <br />
CI4 Team <br /><br />

{company_footer}

<link rel="stylesheet" href="{custom_skin_tmpl}" />

Perhaps all other add-ons like the conditions are just helpers for cases such as multiple emails are needed and the recipient's name isn't directly available {recipient_name}. It doesn't look much but it also takes the pain in creating the for-loop of the UL items. If I'm not a dev guy, this would be awful to work with:

Code:
<ul>
 <?php foreach($items as $item){ ?>
    <li><a href="<?php echo $item->url; ?>"><?php echo $item->name; ?></a></li> <br />
 <?php } ?>
</ul>

It's easy for PHP devs to work with it, but to anyone else, PHP codes might look a bit dyslexic https://s-media-cache-ak0.pinimg.com/236...de789d.jpg.
Long live CodeIgniter!
Reply




Theme © iAndrew 2016 - Forum software by © MyBB