Inline helper methods

[duckbox]

Hey guys, stellar work on this port.

I am having trouble on rendering singular helpers. For example,

{{fullName author}}

fullName being the name of the helper. It works fine if I have a # at the beginning, signifying a block expression. Is there functionality ported to register singular helpers to be used without a # ? If so, what do I need to do to register that helper.

If not, would it be difficult to put it in ?

[everplays]

Hey,

I would like to see that too.

have a look at 172th and 175th lines of Template.php file, that's where {{foo}} gets replaced by $context->get('foo'). probably changing _variable should be far easier but I think it's better to keep what it does as simple as possible and have another method that checks if there's any helper registered with $current[Tokenizer::NAME] and if there wasn't, it calls _variable.

[duckbox]

Thanks for the speedy response!

I'll have a look into that, I came up with a weaker method of checking the template source before compile, to correct any matching helpers,

if {{fullname => {{#fullname etc

Out of curiosity, if you could help, on registering helpers, I've only successfully added them in the actual Helper class.

Is there a more specific example of how to add them outside of the class with a Handlebars instance ?

[everplays]

there's no need to do that, you can have your own helper class and register helpers like $handlebars->addHelper("foo", array("Namespace\\MyHelpers", "foo_method")) or just use closures like

$handlebars->addHelper('foo', function($template, $context, $args, $source) {
    ...
});

you can use anything that makes is_callable happy.

anyways, I keep this open until we fix calling helpers with {{helperName args}} syntax.

[duckbox]

@everplays Amazing. Again thank you.

[yuta1228]

Hello, I'm running into similar issue. Would love to see this as well.

I tried to modify the src to have it working, and my finding was that, for one, when doing with {{helperName args}} Tokenizer doesn't recognize the arguments, so I added T_ESCAPED, T_UNESCAPED, T_UNESCAPED2 to argument interpretation and expanded the Template.php in cases for types above to; if it has argument, run the _section instead of _variables.

It did work, but then it mis-interrupted the variable with path i.e ../variable

using php-52 version btw.

thanks for the cool port :+1:

[everplays]

@yuta1228 I don't understand, why it would interrupt ../variable? $context->get handles 'em which won't be touched at all.

[yuta1228]

Sorry, let me try to make it clear.

So I was testing Tolkenizer::scan to let in Tolkenizer::T_ESCAPED Tolkenizer::T_UNESCAPED Tolkenizer::T_UNESCAPED2 to checking if these type has arguments.

It would have ../variable go in for scan to see if it has arguments, and somehow it was interpreted as helper when it got to Template::render.

I found out that when checking those types for arguments, it should not default to have args variable default to empty string as it does in case for Tolkenizer::T_SECTION and others.

Once that was taken care of it seems to have no problem.