Agreed, but we can combine those aproaches. For simple projects we can use Facade, but advanced user can type more.
And I think it is, in general, a viable approach. To give 2 options in framework, easy and highly customisable. Easy way would help new people to start and the hard way gives satisfaction to users with high requirments. “Easy to get, hard to master”
@rob006 implemented it like the following.
Setting/overwriting helper locally:
$view->render('index', [
'html' => new Html(),
]);
Setting helper globally:
$view->setDefaultParameters([
'html' => new Html(),
]);
Local overrides global in case name is the same.
If I’m writing an extension, how can I rely on this? If html helper will not be configured in default parameters at app level, then it will not be available in view - I need to inject Html instance myself to make sure that it is available. But in that case end user will not be able to overwrite this helper at app level.
What would you suggest?
I don’t know, but this should be more like a contract than optional feature.
On the other hand in view you could do something like:
$html ??= new Html();
And it would work as intended - helper can be injected at view or controller level, with default fallback. It should also work like a typehint (IDE should recognize that $html is Html instance).
A view should be an object taking params, so html would be a param.
An extension using views, has params too.
So you would pass a Html object to the view/extension. Well its up to the extension developer what he wants to be customizable.
He could also prevent manipulation of a(), by not providing any params for those methods/objects.