Handlebars PHP 5.4 - with new helpers, array slice and more

[mardix]

Hello world, I made some updates that I think the rest of the community could benefit from.

1. Requires PHP 5.4. > PHP 5.2 is out of the game and 5.3 is quickly following in the grave

2. Added {{else}} in {{#each}} . Else in each allow us to do something else if the Array is empty, instead of using {{#if}}

   {{#each Array}} something {{else}} Nothing found {{/each}}

3. Added slice in each Array, to slice the data to display

   {{#each Array[start:end]}}

Get the 10 items

{{#each array[0:10]}}
    {{.}}
{{/each}}

Get the last two

{{#each array[-2:]}}
    {{.}}
{{/each}}

more:

• {{#each Array[start:end]}} = starts at start trhough end -1
• {{#each Array[start:]}} = Starts at start though the rest of the array
• {{#each Array[:end]}} = Starts at the beginning through end -1
• {{#each Array[:]}} = A copy of the whole array
• {{#each Array[-1]}}
• {{#each Array[-2:]}} = Last two items

• {{#each Array[:-2]}} = Everything except last two items

  1. Fix a bug in {{@key}} where if an array has one key/value element, it will not display @key
  2. After create $handlebars, your can render by using it as function:

  echo $handlebars("Hello {{you}}", ["you" => "me"]);

  3. A better documentation
  4. Change arrays from array to [](php 5.4)
  5. Cleanup

[wwwsevolod]

What about backward compatibility with handlebars.js? What about "logic less templates" that u ruined when u added slices? This is bad

[mardix]

Thanks for the feedback.

To answer you, well, {{#each}} still has the same behavior without the slicing part. But since each, and some other expressions are just helpers, I believe it's best to extend some functionality to give us a little bit more power over the data. So yes, it is still compatible with handlebars.js.

Unlike Mustache, handlebars allows some logic in the template, hence the helpers we have. I don't think I ruined anything, instead I made an improvement that could benefit all of us. I came from Mustache to Handlebars because of the strict logic-less where I then had to put template logic into my php/controllers. Whatever I wanted to do I had to go back to the controller and add something to alter the view. Now image you have an array $MYARRAY that has 20 items, but you would like to share part of the same data in three parts in your view. Before you would have to create 3 data model (array) in your php with the exact size you want to output. First violation, DRY (don't repeat yourself) principle wasn't respected. Now imagine you want to change one size, you now have to go back again in your controller and modify. Your controller is actually dictating how your view should display the data, which it shouldn't. But with the new slice I added, 1) you can now cut (slice) several parts of the array and place them wherever 2) You let the controller feed your data, without altering how it controls the view.

So I believe it is a GOOD addition.

[wwwsevolod]

@mardix you added new syntax ([]). you can slice it before binding to template. control your data outside of templates. about mustache - you can use some kind of helpers in mustache too, they called lambdas in it. they can't get custom arguments and called in context they passed, but you can use them.

Created new syntax ([::]) - can't use it in other handlebars engines, like for ruby or js or obj-c. Who will add this addition to all handlebars engines? me? no, you? no! so you can't just break syntax, if you want - fork it and create your own "logicmore template engine".

i'm not owner of this repo and i don't no what they decide on this pull request, but it seems bad to me, not bcz it is too bad to use, but because compatibility. i use same template files on php, ruby and javascript, not created only by me, for example.

[everplays]

thanks @mardix, some of changes are nice (@key bug fix, readme, each-else, __invoke, ...) but I agree with @wwwsevolod about helpers, not just slice thing but everything that's not in handlebars.js. instead of trying to modify handlebars.php you could introduce a collection of helpers and I would be more than happy to introduce your helpers collection in readme. if you google, you can find a few helpers collections for handlebars.js (https://github.com/elving/swag for example)

I don't want to add stuff that makes handlebars.php incompatible with handlebars.js, the point of creating handlebars.php was to use same templates that you could use with handlebars.js.

other than above, I don't understand why you've removed PHPCodeSniffer and PHPUnit from development dependencies. It would be pretty nice if you could write tests for stuff that you fixed (i.e. @key problem).

[mardix]

I totally understand where you are coming from. If you don't want to use slice, you can omit it from your code. It's not required. {{#each Array }} {{/each}} still work the same way.

About mustache, yes I know you can use lambda, but once again that's dictating the views from the controller in my opinion.

Also, I hope that you (the community) know the reason for Handlebars.js was because of the limitations of Mustache. Yes I added a new syntax, but it's an extension to what's already there. And I believe it's a good addition. It extends a EACH helper. EACH itself is a helper and not strict to handlebars.js, just like IF, UNLESS etc...

If it will affect your other templates, you can either implement the slice functionality in your other languages, or not use the slice at all.

Also, I think that's a bad attitude to just throw me away like that by saying "if you want - fork it and create your own "logicmore template engine"". The attitude of "not invented here" is not a good one. It is destructive and bring nothing to the table. And if I leave and do my own, what does that do to the community? Also, anyone reading this seeing this type of attitude will be shy to bring anything new in Handlebars itself.

If I created something I think that's a good solution to be shared, you should not be throwing me or any ideas away like that. While something may not fit for you, doesn't mean someone else won't benefit from it.

In my opinion this is a good addition.

[mardix]

@everplays sorry about the PHPCodeSniffer and PHPUnit , I think when I was wroking on the Readme file, I removed it because it was causing my editor to act crazy.

[wwwsevolod]

@mardix

The attitude of "not invented here" is not a good one.

if you are really think that it needs to be in core of engine - talk to each other implementation owner. you can't just break backward compatibility, and if you didn't understand this - i don't know how not to yell on you, sorry

[boukeversteegh]

I also think that extending handlebars syntax into the core is a bad idea. It will lead to incompatibilities: You let frontenders write handlebars templates for handlebars.php, and when you decide you want to do some clientside parsing, suddenly your templates are not compatible because php-specific syntax was used.

In my opinion, any feature that doesn't exist in handlebars.js should be part of a separate helper, like {{#slice}}. Although I appreciate the idea, and I agree that it would be useful, I object to making handlebars.php-templates incompatible with handlebars.js-templates.

I'm looking for a handlebars implementation for PHP that will do exactly what handlebars.js does, and nothing else. I don't want to think about which features are supported by which implementation. Remember how websites got broken in the past because every browser had their own (useful) extensions to HTML that were not supported in other browsers? Let's learn from the past.

[mardix]

@boukeversteegh @everplays OK guys, thank you. I like how you approached this situation with a positive sense. I'll bring an update later on today.

Thanks.

[d1rk]

I also appreciate the work and output @mardix created. I see, why it is a bad idea to patch that into core without further thinking. But having it available as an addon/plugin/helper would be awesome for those, who just use php-based templating with handlebars.

Even cooler would be, to have (at least) js-equivalent helpers that provide the same functionality.

[mardix]

@d1rk, thank you. I will do that.

[d1rk]

@mardix that's great news. Looking forward to it.