Welcome Guest, Not a member yet? Register   Sign In
HelpfulParser - Need testing

[eluser]Phil Sturgeon[/eluser]
I have knocked up a modification to the CodeIgniter Template Parser, which I am calling "Helpful Parser".

Helpful Parser allows you to use helper functions in your Parser view files using a special syntax like the examples below. It will also load any helpers you try to use to save you having to load them yourself within the controller.

Pastie: libraries/MY_Parser.php

Quick examples


Repeat string
{string:repeater["repeat this<br/>"|10]}


Native PHP func

I have put together a test controller and view file too.

When this is all tested and feedback has been given, I will set up the demo and download links.

I think it's a fun way to lazy load helpers but i wonder about the benchmarks.

What started the idea? Is it really that bad/difficult to load the helpers in the controller?

In the case of the form helper why not use the prefix once or write something like
It doesn't make much sense to check if the helper is loaded each time a function from that helper is called.

It's a clever idea but i think it hasn't much real world value.

[eluser]Phil Sturgeon[/eluser]
You are right. The loader performs the check with 2 if statements and a foreach which really doesn't need to be done.

I have reduced the number of "things" it has to do by making the following improvement:

// If there is a helper file (not a native PHP function) and it has not yet been loaded
        if(!empty($helper) && !array_key_exists($helper, $CI->load->_ci_helpers))
            // This includes the helper, but will only include it once


I started this not just to add lazy-load, but so helpers could actually be used within the parser class. I have modified the parser to also parse strings so this means I can have helpers being used by end users within database submitted content (i.e page managers).

[eluser]Phil Sturgeon[/eluser]
In the mean-time, this is all up on GitHub.


I think if you really aim for the end user the syntax is too difficult. Are you going to burden and end user to learn which helpers are available and which functions they add? And what if people start mixing functions?

[eluser]Phil Sturgeon[/eluser]
They can't mix.

All it needs is a simple guide page. I don't know how the hell to use Markdown or Textile until I hit the "Syntax Help" box and take a look. I will also be modifying TinyMCE to insert these.

That takes care of the end users, what about developers wanting to use parser over views + PHP? Designers skinning CI applications?

This syntax is not so different from Smarty modifiers. In fact, I would say easier for complex functions with more than one parameter as the order is more logical. A direct comparison against a Smarty modifier equivalent would be:



It means you are not modifying a variable and adding whole new meaning to its output, you are saying you want to use the variables as part of a function. That makes a whole bunch more sense.

End users wont get it right away, but this will help CMS creators allow clever input, and allow designers/developers of other apps to get their view files using much cleaner parser files.

You are right, if you introduce a new way of adding data to static files there will be some learning curve. And creating a TinyMCE plugin will make it easier to include the syntax but i think the dumber you can make it the more people you can attract to use it.

Mentioning Smarty gives the code negative credits in my book. I think Smarty it modeled too much after php which makes it developerfriendly but not user/designerfriendly. If a designer sees
<a href="&lt;?php echo $some_link ?&gt;">&lt;?php echo $some_title ?&gt;</a>
He/she only has to learn html, which can be used for many things, and understand between &lt;?php and ?&gt; are the variables. And it doesn't requires a parser and a function call to output the content.

As far as templating engines go i'm still a big fan of phptal, from the frontpage;
<div class="item" tal:repeat="item itemsArray">
    <span tal:condition="item/hasDate" tal:replace="item/getDate"/>
    <a href="${item/getUrl}"content="item/getTitle">
  <p tal:content="value/getContent"/>
The anchor element in phptal also needs some learning but it's more htmlly.

I tip my hat coming up with the idea but i see more bad sides than good.

[eluser]Phil Sturgeon[/eluser]
That is designer friendly?

Im pretty sure that the syntax below is more friendly for everyone, especially seeing as it is based on the syntax already used in the Parser.

<div class="item">
   <a href="{url:site_url[$url]}">{title}</a>

This has highlighted two small modifications I need to introduce though: String and Variable concatenation and variable access within loops.

[eluser]Phil Sturgeon[/eluser]
HA! I didn't need to add in variable support at all, it does that already.

  <div class="item">
    <a href="{url:site_url['controller/{item_url}']}">{item_title}</a>

That works perfectly fine. You can concatenate too.

Not sure I like that syntax much though...

[eluser]Phil Sturgeon[/eluser]
Anyone got any feedback on this? Or suggestions for better syntax?

Theme © iAndrew 2016 - Forum software by © MyBB