view helpers and html project

[Michael Kimsal]

I'm somewhat new to aura - been using various pieces for last couple of months, and digging it (thanks!)

I can't seem to find a way to use the html helpers with my view while also using my own helpers.  The examples all show just passing one helper factory to the view instance.  Any new helpers I try to register with 'set' don't seem to work right

        $h = $view->getHelpers();

        $h->set("foo", function() {

// do something here

        });

This would let me use $this->foo() in a view, but after adding the HTML helpers, none of this works anymore - I get errors like "Warning: Missing argument 1 for lib\ViewParse::lib\{closure}(), called in /var/www/vendor/aura/html/src/HelperLocator.php on line 118"

Is there any way to have my own custom helpers as well as use the HTML escaper helpers from the HTML project?  Or does everything now have to conform to the HTML project helper pattern (which, AFAICT, also requires every helper to accept an 'escaper' parameter, which doesn't really jive with my custom helpers).

Any direction/advice would be appreciated.

Thanks.

[Paul M. Jones]

> On Jun 9, 2015, at 08:44, Michael Kimsal <mgki...@gmail.com> wrote:
>
> I'm somewhat new to aura - been using various pieces for last couple of months, and digging it (thanks!)
>
> I can't seem to find a way to use the html helpers with my view while also using my own helpers. The examples all show just passing one helper factory to the view instance. Any new helpers I try to register with 'set' don't seem to work right
>
> $h = $view->getHelpers();
> $h->set("foo", function() {
> // do something here
> });
>
> This would let me use $this->foo() in a view, but after adding the HTML helpers, none of this works anymore - I get errors like "Warning: Missing argument 1 for lib\ViewParse::lib\{closure}(), called in /var/www/vendor/aura/html/src/HelperLocator.php on line 118"

Here's the fundamental difference:

- The HelperRegistry built into the View package is simpler and expects closures or pre-built callable objects (it's only a Registry so it handles only object retrieval). It gets you off the ground fast.

- The HelperLocator of Aura.Html is somewhat more complex, and expects *factories* for the helper objects (it's a Locator so it also handles object creation). It servers better for longer-term maintenance.

That makes them very different systems. Being able to use very different helper systems in Aura.View is both a pro and a con; it's a pro because you get to use what you want, but it's a con because you have to change how you think when you move to a different system.

The solution here is to write your helpers as invokable objects, and pass a factory closure to the Aura.Html HelperLocator. For example:

```php
class FooHelper
{
public function __invoke()
{
// do something here
}
}

$h = $view->getHelpers();
$h->set('foo', function () { return new Foo; });
```

Let me know if that helps.




--
Paul M. Jones
pmjo...@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

[Paul M. Jones]

Minor followup. This ...

> $h->set('foo', function () { return new Foo; });

... should be this:

$h->set('foo', function () { return new FooHelper(); });

Hope that helps.

[Michael Kimsal]

*mostly* helps thank you! Still have a big of undoing to do - went down too man ratholes and had too many loose ends tripping over each other in this branch.

--
You received this message because you are subscribed to a topic in the Google Groups "The Aura Project for PHP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/auraphp/bvg6x0PiEsQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to auraphp+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Michael Kimsal
http://kims.al
919.827.4724

[Hari K T]

Hi,

 

*mostly* helps thank you! Still have a big of undoing to do - went down too man ratholes and had too many loose ends tripping over each other in this branch.

I will suggest you to use Aura.Html + Aura.View . So that the complexity can be reduced.

$factory = new \Aura\Html\HelperLocatorFactory;

$helpers = $factory->newInstance();

$view_factory = new \Aura\View\ViewFactory;

$view = $view_factory->newInstance($helpers);

Now you can add your own custom helpers to the Aura.Html helper  as Paul himself have mentioned very clearly . Or you can have a look at https://github.com/auraphp/Aura.Html#custom-helpers

I did created a repo due to the question raised here earlier : https://github.com/harikt/AuraViewExample

Hope it may help to get some more information.

Thank you.

[Michael Kimsal]

Thanks Hari:

That doesn't seem to address my issue though, in that I don't see an example of using a custom helper outside of the HTML ones.  

I managed to get this working - I was doing what Paul suggested, but hadn't rolled back some earlier variation of an attempt, which ended up causing some conflicts and reinforced that I shouldn't be touching this stuff late at night...

[Hari K T]

Thanks Hari:

You are welcome. :-) .

 

That doesn't seem to address my issue though, in that I don't see an example of using a custom helper outside of the HTML ones.

Ya the one example I created don't have custom helper. But from here you can see 

https://github.com/auraphp/Aura.Html#custom-helpers

and you are adding to $helpers .

I am sure that should work.

 

  I managed to get this working - I was doing what Paul suggested,

Good. 

Enjoy!

[Michael Kimsal]

But that example is specifically using the Aura\Html helper abstract as a base, which has a specific way of loading - it requires passing in an 'escaper', for starters (which not all helpers would need).  This lead to my original issue, which seemed to be that if you used the Aura\Html helpers, *all* custom helpers would need to behave the same way, because there's only one 'helper' factory that can be passed to a view.  Registering direct invokable objects via ->set seems to work, even if it's a bit (to me) counter intuitive.

--

You received this message because you are subscribed to a topic in the Google Groups "The Aura Project for PHP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/auraphp/bvg6x0PiEsQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to auraphp+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Hari K T]

But that example is specifically using the Aura\Html helper abstract as a base, which has a specific way of loading - it requires passing in an 'escaper', for starters (which not all helpers would need).

 but it's not required. It is already stated on Readme .

>  helper class needs only to implement the `__invoke()` method.  We suggest extending from _AbstractHelper_ to get access to indenting, escaping, etc., but it's not required.

 

  This lead to my original issue, which seemed to be that if you used the Aura\Html helpers, *all* custom helpers would need to behave the same way, because there's only one 'helper' factory that can be passed to a view.  Registering direct invokable objects via ->set seems to work, even if it's a bit (to me) counter intuitive.

gists may help to understand.

I did have created lots of helpers but have not came across any issues.

Eg : https://github.com/friendsofaura/Aura.Blog/tree/master/src/Html/Helper 

Yes in those I did extended the Abstract class but again its not required and have nothing to do.