ZF2 Skeleton & Environments Revisited

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

ZF2 Skeleton & Environments Revisited

ralphschindler
Hey all,

I've been tinkering and thinking about how we decided to solve the
problem of environments in ZF2's skeleton, and wanted to know how we
felt about it, and if it's something we might want to consider changing
in the future.

In ZF1, we had built-in concepts of 'production', 'staging', and
'development'.

In ZF2, we transitioned to a concept of global configuration (travels
with the codebase), and local configuration (that is intended to be
configured on the server it is deployed to.


Here are some of my thoughts


   * In the future, I envision that there will be more "development
time" tooling, especially tooling that is exposed through the webui and
served up by the web servers "user".  The problem is if these tools
write config or code, they do so not as the developer but as the
webserver user.

   * In some cases, you wouldn't want certain dev time modules enabled
in your production or staging environment (think /admin utilities that
set things like db usernames and passwords, or "installer" scripts).

   * Currently, the skeleton has no concept of environment specific modules.


This begs the questions:


   * Should we re-consider specific environments becoming first class
citizens again: production, staging, qa, development- for example?

   * And if so, should our skeleton and perhaps the framework support
these concepts (think in addition to an application.config.php, but also
a development.config.php where development only modules might be loaded.)


What does everyone think?

-ralph
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Skeleton & Environments Revisited

Marco Pivetta
We covered that many and many and many times. `config/application.config.php` is just a PHP file - people can add logic there if they need dynamically loaded modules.



On 8 August 2013 22:56, Ralph Schindler <[hidden email]> wrote:
Hey all,

I've been tinkering and thinking about how we decided to solve the problem of environments in ZF2's skeleton, and wanted to know how we felt about it, and if it's something we might want to consider changing in the future.

In ZF1, we had built-in concepts of 'production', 'staging', and 'development'.

In ZF2, we transitioned to a concept of global configuration (travels with the codebase), and local configuration (that is intended to be configured on the server it is deployed to.


Here are some of my thoughts


  * In the future, I envision that there will be more "development time" tooling, especially tooling that is exposed through the webui and served up by the web servers "user".  The problem is if these tools write config or code, they do so not as the developer but as the webserver user.

  * In some cases, you wouldn't want certain dev time modules enabled in your production or staging environment (think /admin utilities that set things like db usernames and passwords, or "installer" scripts).

  * Currently, the skeleton has no concept of environment specific modules.


This begs the questions:


  * Should we re-consider specific environments becoming first class citizens again: production, staging, qa, development- for example?

  * And if so, should our skeleton and perhaps the framework support these concepts (think in addition to an application.config.php, but also a development.config.php where development only modules might be loaded.)


What does everyone think?

-ralph

Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Skeleton & Environments Revisited

Ralf Eggert
In reply to this post by ralphschindler
Hi Ralph,

currently I use the ZF1 way within my ZF2 apps. /public/index.php looks
like this:

-----------------------------------------------------------------------
// define application environment
define('APPLICATION_ENV', (getenv('APPLICATION_ENV')
                           ? getenv('APPLICATION_ENV')
                           : 'production'));

// get configuration file
switch (APPLICATION_ENV) {
        case 'production':
            $configFile = 'config/production.config.php';
            break;
        case 'development':
        default:
            $configFile = 'config/development.config.php';
            break;
}

[...]

// Run the application!
Zend\Mvc\Application::init(include $configFile)->run();
-----------------------------------------------------------------------

This simply works and is easily extendable. In the /config/autoload/ dir
I also have a global.php and then a production.php and a development.php
which are loaded by this:

-----------------------------------------------------------------------
        'config_glob_paths'   =>
            array('config/autoload/{,*.}{global,production}.php'),
-----------------------------------------------------------------------

I noticed that ZF2 beginners understand this much faster than the
global.php / local.php stuff...

Jm2c!

Thanks and best regards,

Ralf
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Skeleton & Environments Revisited

ralphschindler
On 8/8/13 4:14 PM, Ralf Eggert wrote:

> define('APPLICATION_ENV', (getenv('APPLICATION_ENV')
>                             ? getenv('APPLICATION_ENV')
>                             : 'production'));
>

...

> I noticed that ZF2 beginners understand this much faster than the
> global.php / local.php stuff...
>

Yep, just like how we had in ZF1.  And the beginner thing is exactly the
point I am hoping to address as well.

For all intents and purposes, everyone that wrote ZF1 apps knew that
having a APPLICATION_ENV present was kind of a "best practice".

Thanks!
Ralph


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Skeleton & Environments Revisited

ralphschindler
In reply to this post by Marco Pivetta
On 8/8/13 4:06 PM, Marco Pivetta wrote:
> We covered that many and many and many times.
> `config/application.config.php` is just a PHP file - people can add
> logic there if they need dynamically loaded modules.


The point is, since it requires custom logic, that means

   1) there is no standardized solution

   2) which ultimately means people can't write "for development only"
modules, thus the onus is on the consumer to ensure its only available
in "development".

Basically, global/local is a first class solution for configuration, but
we have no first class solution for environment specific modules.

The ultimate question is, "is what we've done enough?"

I'm guessing your answer to that question is: yes

-ralph

Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Skeleton & Environments Revisited

Artur Bodera

On Thu, Aug 8, 2013 at 11:39 PM, Ralph Schindler <[hidden email]> wrote:
Basically, global/local is a first class solution for configuration, but we have no first class solution for environment specific modules.

The ultimate question is, "is what we've done enough?"

I've been trying to advocate for that 2 years ago and then a year ago, when we were discussing config merging, globs and other stuff.

Ultimately, I've also resorted to working with APPLICATION_ENV env variable (similar to ZF1) which is then used to load different glob sets of configs (basically following the local/global, production/devel logic).

The most peculiar thing I had to work around is enabling and disabling modules - that means I had to have a separate application.config switching logic, because the module path and module array live outside of the app config scope.


That said, I'd start considering cleaning that up by considering ways of including module manager config inside application, so there was a monolitic config for everything, which then can be branched for dev and production.
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Skeleton & Environments Revisited

Marco Pivetta
On 8 August 2013 23:57, Artur Bodera <[hidden email]> wrote:

That said, I'd start considering cleaning that up by considering ways of including module manager config inside application, so there was a monolitic config for everything, which then can be branched for dev and production.


Let's avoid that please. There's two very specific steps in an application:

 * Setup (pre-application-object-instantiation) - module manager's world
 * Run (onBootstrap til end) - Zend\Mvc world

It is VERY important to keep this separation very distinct because that's basically what allows us to:

 * Run multiple application instances with a single bootstrap step
 * Freeze the service manager and potentially make it immutable (mainly for performance reasons)

If we mix that up then we've completely missed the point of a bootstrap step.

No, the application should not know how it was bootstrapped: it should just move on and execute whatever.

I'm perfectly fine with adding dozens of shiny buttons to the skeleton application, but then let's please rethink this poor skeleton a bit and either go one way (add everything) or the other (really reduce it to bones).

The fact that devs still use `APPLICATION_ENV` to work with config switching does NOT mean it's a good practice. I don't even think the glob config merging does need to be put into discussion here, since it helped with:

 * getting rid of passwords in SCM
 * getting rid of machine-specific configs in SCM
 * allowing developers to just drop (and rename) a `.dist` file provided by a random module developer into `config/autoload/`
 * allowing inclusion of globals that may come from an environment specific path (the GLOB could be something like `{/etc/mystuff/some-base-config.php,config/autoload{global,local}.php}`
 * other things that sleep deprivation currently prevents me to think of

For the `config/application.config.php`: well, even here we shouldn't probably suggest using anything coming from the environment to switch enabled modules. That's a fragile mechanism that complicates deployments and makes it easier to break stuff in my opinion. ZF2 fortunately _rarely_ relies on the environment or modifies it, and that is a GOOD thing, because it maximizes portability and reduces breakages.

Introducing environment based switches here may bring to funny cases of `why the heck is the production server serving the dev toolbar?`. I'd simply suggest not to commit such changes to your config to SCM to be honest. That's how I work on my dev machine.

At the end of the day, for the most of those working with a `DEV_ENV` switch (or similar) it is really about either not committing a `.htaccess` or not committing a `config/application.config.php`. I'd prefer not committing the latter.

My 2 cents.

Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Skeleton & Environments Revisited

Sascha-Oliver Prolic
Perfect explanation Marco, couldn't have said better, +1

Sascha

Sascha-Oliver Prolic


2013/8/9 Marco Pivetta <[hidden email]>
On 8 August 2013 23:57, Artur Bodera <[hidden email]> wrote:

That said, I'd start considering cleaning that up by considering ways of including module manager config inside application, so there was a monolitic config for everything, which then can be branched for dev and production.


Let's avoid that please. There's two very specific steps in an application:

 * Setup (pre-application-object-instantiation) - module manager's world
 * Run (onBootstrap til end) - Zend\Mvc world

It is VERY important to keep this separation very distinct because that's basically what allows us to:

 * Run multiple application instances with a single bootstrap step
 * Freeze the service manager and potentially make it immutable (mainly for performance reasons)

If we mix that up then we've completely missed the point of a bootstrap step.

No, the application should not know how it was bootstrapped: it should just move on and execute whatever.

I'm perfectly fine with adding dozens of shiny buttons to the skeleton application, but then let's please rethink this poor skeleton a bit and either go one way (add everything) or the other (really reduce it to bones).

The fact that devs still use `APPLICATION_ENV` to work with config switching does NOT mean it's a good practice. I don't even think the glob config merging does need to be put into discussion here, since it helped with:

 * getting rid of passwords in SCM
 * getting rid of machine-specific configs in SCM
 * allowing developers to just drop (and rename) a `.dist` file provided by a random module developer into `config/autoload/`
 * allowing inclusion of globals that may come from an environment specific path (the GLOB could be something like `{/etc/mystuff/some-base-config.php,config/autoload{global,local}.php}`
 * other things that sleep deprivation currently prevents me to think of

For the `config/application.config.php`: well, even here we shouldn't probably suggest using anything coming from the environment to switch enabled modules. That's a fragile mechanism that complicates deployments and makes it easier to break stuff in my opinion. ZF2 fortunately _rarely_ relies on the environment or modifies it, and that is a GOOD thing, because it maximizes portability and reduces breakages.

Introducing environment based switches here may bring to funny cases of `why the heck is the production server serving the dev toolbar?`. I'd simply suggest not to commit such changes to your config to SCM to be honest. That's how I work on my dev machine.

At the end of the day, for the most of those working with a `DEV_ENV` switch (or similar) it is really about either not committing a `.htaccess` or not committing a `config/application.config.php`. I'd prefer not committing the latter.

My 2 cents.

Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Skeleton & Environments Revisited

Gregory
In reply to this post by Marco Pivetta

On Thu, Aug 8, 2013 at 5:50 PM, Marco Pivetta <[hidden email]> wrote:
On 8 August 2013 23:57, Artur Bodera <[hidden email]> wrote:
 That's how I work on my dev machine.

At the end of the day, for the most of those working with a `DEV_ENV` switch (or similar) it is really about either not committing a `.htaccess` or not committing a `config/application.config.php`. I'd prefer not committing the latter.

Trying to carefully understand this leads to some questions:

What happens when you want all dev environments to have a certain set of configuration and then maybe actually apply a local (i.e individual developer specific set of configurations)?

What happens if I want a tool to setup projects dependent on which machine its on (i.e development, staging, production) - there has to be an environment param specified to automate this?

It also seems that by not provisioning access to an environment param, e.g getEnvironment(), regardless of how it is set, means everything has to become highly configurable. No conditional logic is actually removed, it just forces a specific flag for every condition rather than simply an environment one?

Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Skeleton & Environments Revisited

Marco Pivetta

On 9 August 2013 02:44, Greg <[hidden email]> wrote:

What happens when you want all dev environments to have a certain set of configuration and then maybe actually apply a local (i.e individual developer specific set of configurations)?


In a corporate environment you could probably distribute a file that goes in a specific location of developer boxes. `/opt/local/somestuff/developers-developers.php`

 
What happens if I want a tool to setup projects dependent on which machine its on (i.e development, staging, production) - there has to be an environment param specified to automate this?

Since the tool is the guy aware of the environment (provisioning tool, typically) it should probably just drop a file in `config/autoload` instead of assuming that the app knows the environment too.
 

It also seems that by not provisioning access to an environment param, e.g getEnvironment(), regardless of how it is set, means everything has to become highly configurable. No conditional logic is actually removed, it just forces a specific flag for every condition rather than simply an environment one?

Not sure I get this part :)
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Skeleton & Environments Revisited

Gregory
I think I understand more now, but it is more work.

E.g the application's SCM could have autoload/app.dev.php.dist and autoload/app.staging.php.dist. The tool would copy these to autoload/app.local.php which is not in the SCM and would allow the developer to make changes to that file without affecting others (or the SCM). It just means if the dev wants to propagate say a new development configuration to others, he would have to update the app.dev.php.dist and everyone would need to reload their configuration.

And as for the everything is configurable issue, this ensures that third party modules are not tied to, or targeting, specific environments.

So it sounds like each project application should not have config/application.config.php in the SCM, but rather config/application.config.php.dev, config/application.config.php.staging and config/application.config.php.production, and the tool would rename the file depending on the environment param provided. Just means adding a new module could mean updating those three distribution files as well as creating any new autoload config files (e.g autoload/mod.dev.php.dist) - and manually refreshing the config/app.config.php file.

So should modules support environment specific configuration distribution files instead? I.e they should not provide a mod.local.php.dist, but can provide a mod.php.dist (aka global/production), mod.php.dev.dist, and a mod.php.staging.dist, if so desired?

I think I've talked myself into agreeing with both you and more or less what Ralph is suggesting: "in addition to an application.config.php, but also a development.config.php where development only modules might be loaded".




On Thu, Aug 8, 2013 at 7:53 PM, Marco Pivetta <[hidden email]> wrote:

On 9 August 2013 02:44, Greg <[hidden email]> wrote:

What happens when you want all dev environments to have a certain set of configuration and then maybe actually apply a local (i.e individual developer specific set of configurations)?


In a corporate environment you could probably distribute a file that goes in a specific location of developer boxes. `/opt/local/somestuff/developers-developers.php`

 
What happens if I want a tool to setup projects dependent on which machine its on (i.e development, staging, production) - there has to be an environment param specified to automate this?

Since the tool is the guy aware of the environment (provisioning tool, typically) it should probably just drop a file in `config/autoload` instead of assuming that the app knows the environment too.
 

It also seems that by not provisioning access to an environment param, e.g getEnvironment(), regardless of how it is set, means everything has to become highly configurable. No conditional logic is actually removed, it just forces a specific flag for every condition rather than simply an environment one?

Not sure I get this part :)



--
Greg
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Skeleton & Environments Revisited

Kyle Spraggs
First,

I really have no problem with using a local config file. At work we have development (vagrant), staging, and production. Staging mimics production with the exception that errors are shown. We set up all our modules to be ready for production without any extra configuration. This means config files are laid out like:

production - Credentials only (you don't want to commit those to VCS anyway)
staging - Credentials, and an ini_set to enable display_errors.
development - This is where the majority of overrides are done. Caching is disabled, local db credentials are used, ZendDeveloperTools and SpiffyConfig is enabled, etc.

We have dozens of sites and there's not one instance where a setup with a global/local has no been sufficient. To help with the development overrides I ship a config.local.php.dist file with the most common dev setup but each developer should and does tailor that configuration to their own environment.

Second,

I think everyone needs to remember how little overhead is involved in loading a module *assuming* the module is written correctly. There's really no reason for you to be concerned over loading an additional module in production that you won't use. For example, Zend Developer Toolbar you just disable profiling and the toolbar. For SpiffyConfig setting the config value to disabled simply skips registering the RuntimeListener. You spent more time reading this email than your application will ever consume by leaving them in your application and having them disabled in production.

Furthermore, this highlights the power of the global/local config. If a module is written properly (and with config loading in mind) you can just set an enable flag for your development environment (defaults should be production ready, i.e, off).

My 2c.


Kyle Spraggs
"There is a tide in the affairs of men. Which, taken at the flood, leads on to fortune; Omitted, all the voyage of their life Is bound in shallows and in miseries." - WIlliam Shakespeare


On Thu, Aug 8, 2013 at 8:36 PM, Greg <[hidden email]> wrote:
I think I understand more now, but it is more work.

E.g the application's SCM could have autoload/app.dev.php.dist and autoload/app.staging.php.dist. The tool would copy these to autoload/app.local.php which is not in the SCM and would allow the developer to make changes to that file without affecting others (or the SCM). It just means if the dev wants to propagate say a new development configuration to others, he would have to update the app.dev.php.dist and everyone would need to reload their configuration.

And as for the everything is configurable issue, this ensures that third party modules are not tied to, or targeting, specific environments.

So it sounds like each project application should not have config/application.config.php in the SCM, but rather config/application.config.php.dev, config/application.config.php.staging and config/application.config.php.production, and the tool would rename the file depending on the environment param provided. Just means adding a new module could mean updating those three distribution files as well as creating any new autoload config files (e.g autoload/mod.dev.php.dist) - and manually refreshing the config/app.config.php file.

So should modules support environment specific configuration distribution files instead? I.e they should not provide a mod.local.php.dist, but can provide a mod.php.dist (aka global/production), mod.php.dev.dist, and a mod.php.staging.dist, if so desired?

I think I've talked myself into agreeing with both you and more or less what Ralph is suggesting: "in addition to an application.config.php, but also a development.config.php where development only modules might be loaded".




On Thu, Aug 8, 2013 at 7:53 PM, Marco Pivetta <[hidden email]> wrote:

On 9 August 2013 02:44, Greg <[hidden email]> wrote:

What happens when you want all dev environments to have a certain set of configuration and then maybe actually apply a local (i.e individual developer specific set of configurations)?


In a corporate environment you could probably distribute a file that goes in a specific location of developer boxes. `/opt/local/somestuff/developers-developers.php`

 
What happens if I want a tool to setup projects dependent on which machine its on (i.e development, staging, production) - there has to be an environment param specified to automate this?

Since the tool is the guy aware of the environment (provisioning tool, typically) it should probably just drop a file in `config/autoload` instead of assuming that the app knows the environment too.
 

It also seems that by not provisioning access to an environment param, e.g getEnvironment(), regardless of how it is set, means everything has to become highly configurable. No conditional logic is actually removed, it just forces a specific flag for every condition rather than simply an environment one?

Not sure I get this part :)



--
Greg

Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Skeleton & Environments Revisited

Gregory

On Thu, Aug 8, 2013 at 8:44 PM, Kyle Spraggs <[hidden email]> wrote:
There's really no reason for you to be concerned over loading an additional module in production that you won't use.


If it was as simple as a single flag bypassing the rest of the module setup, then fine maybe. But there is the autoloader registration, config, maybe other stuff as a result of the config, e.g routing (?), and last the I looked, the addition of template paths (aka file i/o hunt). Even if it takes a few more negligible milliseconds, that saving could add up to one extra request in the same amount of time?




--
Greg
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Skeleton & Environments Revisited

Kyle Spraggs
Autoloading in production should be handled with a classmap. For composer, this is a single file, and I'm sure ZF2's autoloader handles it similarly. Either way, it's opcode cached and is negligible. This also goes for templates - you should be using the template_map for production and only using the path for development. I don't know enough about routing to know whether or not it has a significant impact but in general most modules only have a few routes. Overall, we're looking at microseconds, not milliseconds.


Kyle Spraggs
"There is a tide in the affairs of men. Which, taken at the flood, leads on to fortune; Omitted, all the voyage of their life Is bound in shallows and in miseries." - WIlliam Shakespeare


On Thu, Aug 8, 2013 at 10:42 PM, Greg <[hidden email]> wrote:

On Thu, Aug 8, 2013 at 8:44 PM, Kyle Spraggs <[hidden email]> wrote:
There's really no reason for you to be concerned over loading an additional module in production that you won't use.


If it was as simple as a single flag bypassing the rest of the module setup, then fine maybe. But there is the autoloader registration, config, maybe other stuff as a result of the config, e.g routing (?), and last the I looked, the addition of template paths (aka file i/o hunt). Even if it takes a few more negligible milliseconds, that saving could add up to one extra request in the same amount of time?




--
Greg

Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Skeleton & Environments Revisited

ralphschindler
In reply to this post by Kyle Spraggs

> module in production that you won't use. For example, Zend Developer
> Toolbar you just disable profiling and the toolbar. For SpiffyConfig
> setting the config value to disabled simply skips registering the
> RuntimeListener. You spent more time reading this email than your
> application will ever consume by leaving them in your application and

What you're suggesting is that a development time module, similar to
Zend Developer Toolbar, would register its own configuration (via the
vendor/xx/xx/config/modules.config.php files, which includes potentially
registering:

   * routes
   * services
   * controllers
   * listeners
   * etc

And then it should be responsible for making all of those things inert
when the /config/autoload/global.php file does something like this:

array(
   'ZendDeveloperToolbar' => array('enable' => false)
)

...

Is that what you're suggesting?  B/c ensuring routes don't get routed,
listeners don't fire, and controller plugins get deregistered seems like
more of a headache rather than simply conditionally not enabling a
particular module from an application.config.php file or an enviornment
specific version of it.

-ralph

Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Skeleton & Environments Revisited

Kyle Spraggs
Yes, they're registered, but my point is the time required isn't worth worrying about. The sites I work with get 5-12 million page views a day and it's not even on my radar for concern.

As long as your module isn't doing something silly in onBootstrap() I don't see the need to worry about it unless you're getting a ridiculous amount of page views.


Kyle Spraggs
"There is a tide in the affairs of men. Which, taken at the flood, leads on to fortune; Omitted, all the voyage of their life Is bound in shallows and in miseries." - WIlliam Shakespeare


On Thu, Aug 8, 2013 at 11:06 PM, Ralph Schindler <[hidden email]> wrote:

module in production that you won't use. For example, Zend Developer
Toolbar you just disable profiling and the toolbar. For SpiffyConfig
setting the config value to disabled simply skips registering the
RuntimeListener. You spent more time reading this email than your
application will ever consume by leaving them in your application and

What you're suggesting is that a development time module, similar to Zend Developer Toolbar, would register its own configuration (via the vendor/xx/xx/config/modules.config.php files, which includes potentially registering:

  * routes
  * services
  * controllers
  * listeners
  * etc

And then it should be responsible for making all of those things inert when the /config/autoload/global.php file does something like this:

array(
  'ZendDeveloperToolbar' => array('enable' => false)
)

...

Is that what you're suggesting?  B/c ensuring routes don't get routed, listeners don't fire, and controller plugins get deregistered seems like more of a headache rather than simply conditionally not enabling a particular module from an application.config.php file or an enviornment specific version of it.

-ralph


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Skeleton & Environments Revisited

ralphschindler
On 8/8/13 11:10 PM, Kyle Spraggs wrote:
> Yes, they're registered, but my point is the time required isn't worth
> worrying about. The sites I work with get 5-12 million page views a day
> and it's not even on my radar for concern.

I realize it's fast, that is not my concern.

My concern is that if you ship a module that has, for example, a route,
a service, a listener, a few controllers, etc.. then that module also
has to be responsible for somehow making all 5 of those things inert
when the route gets routed to, the listener gets fired, the service gets
pulled or the controller gets dispatched...

OR are you suggesting that when a module sees 'enabled' => false, it
goes through and removes all its route from the route, its listener from
the event manager, the controller from the controller manager, etc.

I'm just trying to get a sense of how much work you want a module writer
to have to do in order to provide development only types of modules.

-ralph

Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Skeleton & Environments Revisited

Kyle Spraggs
I've only used ZendDeveloperTools and SpiffyConfig - neither of which have any routes. That's a valid, concern, however.Ideally, the routes would never be registered. If the routes aren't registered then the controller shouldn't be dispatched and services would never be pulled from the manager.

Unfortunately, I can't think of an easy way to remove the routes.


Kyle Spraggs
"There is a tide in the affairs of men. Which, taken at the flood, leads on to fortune; Omitted, all the voyage of their life Is bound in shallows and in miseries." - WIlliam Shakespeare


On Thu, Aug 8, 2013 at 11:28 PM, Ralph Schindler <[hidden email]> wrote:
On 8/8/13 11:10 PM, Kyle Spraggs wrote:
Yes, they're registered, but my point is the time required isn't worth
worrying about. The sites I work with get 5-12 million page views a day
and it's not even on my radar for concern.

I realize it's fast, that is not my concern.

My concern is that if you ship a module that has, for example, a route, a service, a listener, a few controllers, etc.. then that module also has to be responsible for somehow making all 5 of those things inert when the route gets routed to, the listener gets fired, the service gets pulled or the controller gets dispatched...

OR are you suggesting that when a module sees 'enabled' => false, it goes through and removes all its route from the route, its listener from the event manager, the controller from the controller manager, etc.

I'm just trying to get a sense of how much work you want a module writer to have to do in order to provide development only types of modules.

-ralph


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Skeleton & Environments Revisited

Gregory
In reply to this post by ralphschindler

I'm thinking that disabling a module would not prevent any configuration copied to config/autoloader from loading still?


--
Greg
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 Skeleton & Environments Revisited

ralphschindler
On 8/9/13 12:37 AM, Greg wrote:
>
> I'm thinking that disabling a module would not prevent any configuration
> copied to config/autoloader from loading still?

That is correct.

But currently, we have no standardized way of enabling/disabling modules
based on environment.  That is the conundrum I am trying to get
community feedback on.

-ralph
12