[RFC]: Ship factories, config providers and make use of plugin-installer

[gsteel]

RFC

Q	A
Proposed Version(s)	3.0.0 possibly 2.x.x
BC Break?	Maybe

Goal

#110 - Yet to be merged or approved, adds config providers that help to centralise configuration, removing config from inside HelperPluginManager for example.

It would be useful to provide factories for the key components in view such as the various renderers and plugin managers and expose these config providers (And maybe also Modules for MVC) to the component installer plugin, and also require that plugin in declared dependencies.

The main reason for shipping factories is they provide an opportunity to document in code how these things should be constructed, how they fit together and provide SA tools and consumers concrete examples of what configuration looks like.

Considerations

• It will become easier to customise how mezzio/mezzio-laminasviewrenderer puts these components together
• An out-of-the-box working configuration for MVC/Mezzio
• Provides a clear path to decoration of configured services with delegators without first having to setup a factory
• Documentation for using config providers without the installer plugin.

Proposal(s)

Depending on whether this is first implemented as feature addition in 2.x, Adding final factories for anything that would benefit:

• PhpRenderer
• View
• Template Resolvers
• Plugin Managers
• Rendering Strategies

Additionally, at the same time in a 3.x release or as a separate change, ship factories and add constructors for DI for the many helpers to minimise the amount of "reaching into the view" for hidden dependencies when an Escaper provided to the constructor is all that's really needed. (Also perhaps removing the inheritance tree from helpers where there is no need for it)

[froschdesign]

@gsteel
What do you think about to removing the hard dependency on laminas-servicemanager, especially the plugin managers?

An example can be found in laminas-feed:

• https://github.com/laminas/laminas-feed/blob/269d3e18139c5e09d5741ebf9cc682f826b45952/src/Reader/ExtensionManagerInterface.php
• https://github.com/laminas/laminas-feed/blob/269d3e18139c5e09d5741ebf9cc682f826b45952/src/Reader/StandaloneExtensionManager.php
• laminas/laminas-feed@e5e956d

[gsteel]

@froschdesign

I guess for view helpers, the important thing is aliases used with __call, so it would mean duplicating a lot of functionality already present in SM such as detecting cyclic dependencies, resolved instances, auto-invokables, in-memory registry of constructed helpers etc, if compatibility with existing configuration was to be preserved.

But I guess, if all the plugin manager did was receive a list of aliases mapped to something available in a user-supplied container, then the plugin manager could be really straight-forward.

The configuration BC break would be significant because all those custom helper factories would need to be moved to dependencies.factories from view_helpers.factories, but long-term it's much less code to maintain and a hell of a lot easier to reason about. Also, documenting it shouldn't be too much of a headache. I'm in!

[froschdesign]

…but long-term it's much less code to maintain and a hell of a lot easier to reason about.

That's the idea behind it! 😃