Reduce number of dependencies prior to v3

[weierophinney]

We would like to reduce the number of dependencies prior to version 3 to only the bare minimum required to run an MVC application — without all the bells and whistles. The majority of the components listed in the service configuration of the component are "opt-in", but due to being listed, become hard requirements for end-users.

As such, we need to determine how we can:

• conditionally add components (solved via Composer)
• wire factories from those components into the application configuration when installed
• wire plugin managers from those components into the ServiceListener when installed

Any ideas towards these ends would be tremendously helpful!

Additionally, we need to determine which components are core to the MVC; feedback welcomed!

[Maks3w]

I was thinking in create different metapackages for different use scenarios.

[weierophinney]

@Maks3w That's fine. That's not what I'm asking, though. 😄

I'm trying to determine which components we'll mark as required dependencies of zend-mvc, and how other components, when installed, can notify the application of their factories and plugin managers. Let's keep discussion to those two items, please.

[Maks3w]

which components we'll mark as required dependencies of zend-mvc

For what use case scenario? As I proposed we should consider different scenarios and provide different sets of required packages for those scenarios (metapackages)

how other components, when installed, can notify the application of their factories and plugin managers

1. This should be discussed out of this specific MVC thread.
2. Is this the same issue zend-expressive has?
3. Probably we should turn those metapackages into ZF2 Modules and wire those configs with the standard module bootstrap.

[Maks3w]

Another option could be write a custom Composer installer and write a single file in some place with the config.

[gianarb]

In my opinion the MVC must work without ModuleManager..

MVC + ModuleManager is a perfect feature but it is not necessary for a MVC.. :) but it is only a my opinion.

And a lot of dependencies (loaded by ServiceListener) could be modules that you can choice to use or not..

• Zend\Log
• Zend\Cache
• Zend\Session
• Zend\Authentication

[weierophinney]

which components we'll mark as required dependencies of zend-mvc

For what use case scenario? As I proposed we should consider different scenarios and provide different sets of required packages for those scenarios (metapackages)

This issue is on the zend-mvc repository. I'm talking specifically about the bare minimum required to write an MVC application. When we start talking about usage scenarios, we're talking more along the lines of skeleton packages or meta-distributions — and that belongs in a discussion on the main framework repository (linked). Any discussion of metapackages or installers belongs there. The discussion in here is around the the requirements for the MVC component specifically.

[akrabat]

In my ideal world, MVC would just require:

• EventManager
• ServiceManager
• ModuleManager
• View

(Assuming Router is still part of Mvc, otherwise also Router!)

i.e. what I see as a ZF-Mvc apps is one that uses modules and a view. i.e. a version of skeleton without the i18n bits.

[Maks3w]

I disagree about move metapackages to parent discussion. optional dependencies are defined in each component composer so each component has a set of scenarios

[weierophinney]

@gianarb The plan for v3 is to keep as much BC as possible. Currently, the MVC and ModuleManager have a symbiotic relationship, and we do not plan to change that. You are correct, however, in noting the current components that we might want to start removing as dependencies here: log, authentication, etc. are definitely candidates for removal!

[weierophinney]

@Maks3w

I disagree about move metapackages to parent discussion. optional dependencies are defined in each component composer so each component has a set of scenarios

I've provided scope to ensure that the thread does not become unwieldy and present too many ideas/options/directions, in large part to reduce the BC risk and amount of development time required to implement. Please respect this.