[ZF3] [RFC] Removal of `get([A-Z][A-Za-z]+)Config` methods from modules #5288

Closed
Ocramius opened this Issue Oct 17, 2013 · 73 comments
@Ocramius
Zend Framework member

This is an RFC for a simplification that would help a lot in building ZF applications considering non-cacheable configurations.

Problem

Some configurations rely on closures, service instances and generally non-serializable data that may break the application when config is merged and then cached

Current solution (ZF2)

In order to solve the problem, ZF2 introduced a series of interfaces that allow developers can implement in their Module classes to add configured services programmatically:

  • Zend\ModuleManager\Feature\ControllerPluginProviderInterface
  • Zend\ModuleManager\Feature\ControllerProviderInterface
  • Zend\ModuleManager\Feature\FilterProviderInterface
  • Zend\ModuleManager\Feature\FormElementProviderInterface
  • Zend\ModuleManager\Feature\HydratorProviderInterface
  • Zend\ModuleManager\Feature\InputFilterProviderInterface
  • Zend\ModuleManager\Feature\RouteProviderInterface
  • Zend\ModuleManager\Feature\SerializerProviderInterface
  • Zend\ModuleManager\Feature\ServiceProviderInterface
  • Zend\ModuleManager\Feature\ValidatorProviderInterface
  • Zend\ModuleManager\Feature\ViewHelperProviderInterface

These configurations basically merge data to the already merged config AFTER it is cached. They all act in the same way, just with different naming and providing different config keys. That's a lot of duplicated code, triggered events and inconsistencies. Additionally, we never suggest usage of those methods if not strictly needed, which makes their existence very confusing for those who don't know that.

Suggestion (ZF3)

I hereby suggest removing (deprecating?) all the interfaces mentioned above, and instead introduce something like Zend\ModuleManager\Feature\UnCacheableConfigProviderInterface (suggestions on the name, please!):

namespace Example;

use Zend\ModuleManager\Feature\ConfigProviderInterface;
use Zend\ModuleManager\Feature\UnCacheableConfigProviderInterface;

class Module implements ConfigProviderInterface, UnCacheableConfigProviderInterface
{
    public function getConfig()
    {
        return [/* like before, nothing to see here! */];
    }

    public function getUnCacheableConfig()
    {
        return [
            // replaces `getViewHelperConfig()`
            'view_helpers' => [
                'services' => ['foo' => new SomeHelper()],
                'factories' => [
                    'bar' => function () {/* can't cache this! */},
                ],
            ],
        ];
    }
}

Bonus

With this approach, we can also get rid of Zend\ModuleManager\Feature\LocatorRegisteredInterface, which allows us to have modules like EdpMarkdown register the module as a service:

namespace Example;

use Zend\ModuleManager\Feature\UnCacheableConfigProviderInterface;

class Module implements UnCacheableConfigProviderInterface
{
    public function getUnCacheableConfig()
    {
        return [
            'service_manager' => [
                'services' => [__CLASS__ => $this],
            ],
        ];
    }
}

Benefits

  • we get rid of a lot of triggered events during module loading
  • we get rid of a lot of documentation related to those get([A-Z][A-Za-z]+)Config methods
  • we get rid of Zend\ModuleManager\Feature\LocatorRegisteredInterface
  • we get a minor performance improvement
  • we get a clear understanding of what getUnCacheableConfig does. The name says it for itself
  • we don't need to add more methods in case more plugin managers are added in future

ZF2 BC compatibility

In order to keep BC with ZF2, we can create a Zend\ModuleManager\Listener\Zf2CompatibilityListener, which emulates the same logic of all the current get([A-Z][A-Za-z]+)Config methods. It can be either on by default or opt-in, but that has to be decided

Drawbacks

None so far

TODO

  • discuss naming of getUnCacheableConfig
  • discuss naming of Zend\ModuleManager\Feature\UnCacheableConfigProviderInterface
  • find possible drawbacks
  • get positive or negative feedback (positive feedback gained)
  • discuss Zend\ModuleManager\Listener\Zf2CompatibilityListener being turned on or off by default
  • provide pull request

Conclusions

  • get([A-Z][A-Za-z]+)Config will be removed from the module classes. getConfig will be used
  • Using un-cacheable config will simply be penalized, avoid that. That's it, nothing more
  • We will simply build a listener that verifies if config can be cached safely before attempting caching. That would allow us to throw meaningful exceptions
  • We will provide a listener for ZF2.x compatibility, so that get([A-Z][A-Za-z]+)Config can still be used

That's it, only removal of of methods, and that's perfectly fine. I'll work on a PR as soon as possible.

@GeeH

I'm all for this. 👍

@EvanDotPro
Zend Framework member

Discussed this with @Ocramius in #zftalk and I am 👍. This would also simplify training (or new developer learning curve in general) around these concepts.

@KingCrunch

VolatileConfig?

@macnibblet

Zend\ModuleManager\Listener\Zf2CompatibilityListener should be disabled by default, we should not enable legacy behavior in new zf3 applications.

else 👍

@tfountain

How about getRuntimeConfig() instead of getUnCacheableConfig()?

@akrabat
Zend Framework member

getUnCacheableConfig will get very big if it combines the config in all the currently separate getXxxConfig() methods. Is the idea that we discourage creating closures and make everyone write separate factory classes for every class that needs injection?

@Thinkscape
Zend Framework member

Sounds nice.

@akrabat I doubt you'll ever see that resolved. From my personal experience, a single feature I wrote yesterday required 15 factories depending on each other. It's just much quicker to write closures than to write separate files with factory classes. There's also the benefit of navigation (I can easily see all my 3-5 line factories at a glance, as opposed to opening each separate file). (of course a proper DIC and build would solve it all, but I digress).

The only drawback, (per @akrabat ) I see, is moving again in the direction of arrays-of-arrays-of-arrays which emulate duck-typing, instead of feature-based loading, interfaces and OOP structures.

For example, explaining "in order to add view helper, define getViewHelperConfig() method" you'd be saying "shove it into that big getSomethingConfig() method, but watch out, don't confuse it with getConfig() method". Whatcha say professor @EvanDotPro ? :-)

I'd vote for either getDynamicConfig() or getRuntimeConfig().

@EvanDotPro
Zend Framework member

getUnCacheableConfig will get very big if it combines the config in all the currently separate getXxxConfig() methods.

For the sake of sanity, I would probably suggest something like...

public function getUncachableConfig()
{
    return array(
        'service_manager' => $this->getServiceConfig(),
        'view_helpers' => $this->getViewHelperConfig(),
        // etc
    );
}

Which could also produce a backwards-compatible module.

Is the idea that we discourage creating closures and make everyone write separate factory classes for every class that needs injection?

In my eyes, this is not the purpose. I see nothing wrong with closures and direct services being registered directly in the module class, especially in very, very simple cases like EdpMarkdown. Personally, I think doing it this way simply makes it easier to understand how and why it works the way it does. Right now, you see a lot of people defining things like invokables, etc in getXyzConfig(), which is a waste. Additionally teaching a new developer how the different methods merge into the different config keys after caching is a hassle, whereas this strategy makes it very clear what's going on. Just my $0.02.

@EvanDotPro
Zend Framework member

@Thinkscape yes, I agree about it being easier to explain. As I mentioned to @Ocramius on IRC:

02:46 < EvanDotPro > ocramius: and it'd be easier to explain than "getServiceConfig() is merged under service_manager... getViewHelperCOnfig() is merged under view_helpers" etc

@akrabat
Zend Framework member

@Thinkscape Yes - I'm not a fan of creating a factory classes for a 3 line method either, so do the same as you and am happy with that. I like @EvanDotPro's idea of getUnCacheableConfig() being used to marshall the other methods.

@EvanDotPro
Zend Framework member

I haven't formulated a final opinion yet, but I'm currently leaning towards something like getUnCacheableConfig() as opposed to getDynamicConfig() or getRuntimeConfig().

While not as "fancy" sounding as the alternatives, getUnCacheableConfig() quite clearly states the significance of the method, whereas it has to be implied with the others.

@akrabat
Zend Framework member

It should be getUncacheableConfig() rather than getUnCacheableConfig().

I don't especially like getUncacheableConfig(), but I agree with @EvanDotPro that it's very clear. However, if we're going that way, then getConfig() should probably become getCacheableConfig()

@Ocramius
Zend Framework member

I don't think that the size of getUnCacheableConfig() is a problem. I've always dealt with it even for getConfig() by splitting all in different files, such as:

public function getConfig() // works also for getUnCacheableConfig
{
    return [
        'service_manager' => require __DIR__ . '/../../config/service_manager.config.php',
        'view_gelper' => require __DIR__ . '/../../config/view_helpers.config.php',
        // ...
    ];
}

Just a note on the method naming: please suggest something that is easy to understand.

getUnCacheableConfig() or getLateConfig() or something like that may work.

getRuntimeConfig() suggests a mutable config, which I personally don't think is a good idea. Same for getDynamicConfig(). While making config mutable depending on I.E. the request object is possible, I see it as a possible source of bugs.

@Thinkscape
Zend Framework member

getUncacheableConfig() ... it's a mouthful, there's a spelling requirement, this will cause a lot of trouble and wtf moments. Better use something easier to spell.

getUncacheable getStorable etc. - also seems like trying to explain implementation details - who cares if it's going to be cached or not.

Possible questions:

Q: is getUncacheableConfg() method being invoked in development, when caching is disabled ?
Q: does caching change the order of merging of getCached/getUncacheable config ?

I'd hope to have a name that is more about the semantics and architecture than what the MM is going to do with it later (caching, serialization etc. should not be part of module definition).

@Ocramius
Zend Framework member

Q: is getUncacheableConfg() method being invoked in development, when caching is disabled ?

@Thinkscape yes, getUncacheableConfig() is always called

Q: does caching change the order of merging of getCached/getUncacheable config ?

No. getUncacheableConfig() is always called AFTER merged config was cached or loaded from cache

@Thinkscape
Zend Framework member

Marco, I know answers to those questions, I'm pointing out the ambiguity of the name and possible questions that such method name could raise :-)

@Ocramius
Zend Framework member

@Thinkscape got it. Yes, I don't have better names so far.

@akrabat
Zend Framework member

Calling it the uncacheable config isn't unreasonable as the only reason that it exists is that getConfig() cannot have closures in it's returned array.

@Ocramius
Zend Framework member

@akrabat yes, that's the main reason for it to exist (and it's the same reason for the get([A-Z][A-Za-z]+)Config methods to exist)

@bakura10

I'm for removing completely those in ZF3, for the only reason that it allows us to remove this crap.

By the way, still no zf3 branch/repo ? :(

@Thinkscape
Zend Framework member

We could always reverse it, so getConfig() and getCacheableConfig()... still a mouthful though. @akrabat you don't get a say because you're British and you love long and hard to pronounce or spell words :-)))

@bakura10

@samsonasik , this repo has been here for months. But still empty for months too :).

@Ocramius
Zend Framework member

Changing meaning of an existing method would be a no-go. That's much more of a BC in my opinion. Think carefully and look for a better name first.

@bakura10 I'm still against a separate repo for zf3, but this is not the thread for it. Focus on the issue, please

@macnibblet

I think everyone is against a seperate repo for zf3

@Thinkscape
Zend Framework member

getRuntimeConfig() suggests a mutable config, which I personally don't think is a good idea. Same for getDynamicConfig(). While making config mutable depending on I.E. the request object is possible, I see it as a possible source of bugs.

You're right.. however it doesn't give me much more hint than existing getConfig() which could also be used in that fashion. getRuntimeConfig() looks nice when you put it besides getCachedConfig() (because word "cached" seems opposite to runtime). Or getCallableConfig() ?

Current contenders

public function getConfig();
public function getRuntimeConfig();
public function getDynamicConfig();
public function getCachedConfig();
public function getUncachedConfig();
public function getCacheableConfig();
public function getUncacheableConfig();
public function getUnCacheableConfig();
@Thinkscape
Zend Framework member

@Ocramius If you consider we won't be using serialized closures, getDynamicConfig() makes sense to me (it's dynamic in sense of using scoped, referenced vars and instances with closures, which all change their addresses with each script invocation)

@Ocramius
Zend Framework member

@Thinkscape super_closure is an experimental project. I wouldn't use it anyway ;)

Dynamic can do for me as well. I just hope people don't abuse it =D

@EvanDotPro
Zend Framework member

@bakura10

I'm for removing completely those in ZF3, for the only reason that it allows us to remove this crap.

You mean removing it completely without a getUncachableConfig() alternative? That would mean I cannot create clever, single-file modules like EdpMarkdown that fit on a slide for a talk, so absolutely not. ;)

By the way, still no zf3 branch/repo ? :(

I was put in charge of starting this, but it created a large debate on how it should be handled (branch, vs separate repo, etc), and there was no consensus reached, so I postponed the new repo for now. We'll kick it off soon, but in the meantime, the WIP/RFC issues and PR's here in the ZF2 repo are working perfectly fine.

We could always reverse it, so getConfig() and getCacheableConfig()

Definitely 👎 from me on this, sorry.

I'm also still 👎 for getDynamicConfig() and getRuntimeConfig()`. I can reject names all day, just don't ask me to suggest any. ;)

@bakura10

No Evan, I want the getUncacheable thing. I ust want to remove all the various getXXXConfig and just keep two ones.

@EvanDotPro
Zend Framework member

@bakura10 ahh, gotcha. Then yeah, we're on the same page. :)

@stefanotorresi

👍 on the whole idea.

@akrabat

getUnCacheableConfig will get very big if it combines the config in all the currently separate getXxxConfig() methods. Is the idea that we discourage creating closures and make everyone write separate factory classes for every class that needs injection?

couldn't that be sorted out by providing Zend\Config instances as keys? this way one can still have encapsulated factories and services, but loaded all at once by just one ModuleManager trigger.

@pauloelr

👍

And what about getTransientConfig?
Since it will not be cached, the state of these configs are only transient and will be refreshed on the next call
It's easy to spell, easy to type, easy to read and easy to understand 😃

@Ocramius
Zend Framework member

Looks like a winner to me :)

Any other suggestions?

@samsonasik

👍 for getTransientConfig

@stefanotorresi

getBareConfig ?

'bare' is an antonym of 'cached', so says the dictionary at least, but I'm no native english speaker :p

@texdc

"Can't cache this!" (Hammertime) 👍

@danizord

👍 for Transient

@marc-mabe
Zend Framework member

What about the following config naming (and order)
1. Module::getPreConfig() or Module::getConfigPre()
2. config/autoload/* configuraion files
3. Module::getConfig()
4. cache configuration
5. Module::getPostConfig() or Module::getConfigPost()

@akrabat
Zend Framework member

Transient implies that it will change. This is not accurate description of the difference between getConfig() which is optionally cacheable and getXxxConfig() which cannot be cached.

There's a reasonable argument to just do away with the "uncacheable" config concept altogether and make people write a factories or abstract factories if they care about caching their config.

Then this whole problem goes away and the story is much simpler anyway:

  1. Write your SM closures in getConfig() (i.e. module.config.php) and accept that you can't cache the config.
  2. Don't write SM closures in getConfig() and write either an abstract factory class per module or a factory class per object.

An abstract factory per module wouldn't be that hard to write. The canCreateServiceWithName() just needs to have an in_array() test against the list of services that you're able to instantiate and createServiceWithName is loosely a switch statement with one case for each service in the canCreateServiceWithName() list.

If you know enough to find the skeleton app's module manager cache settings in application.config.php, then you know enough to write an abstract factory.

@GeeH

getClosureConfig for me, and I don't buy the argument that the config will be too long if not separated into individual methods; it's what currently happens with getConfig and nobody complains there ;) Don't forget this method should only return factories that have closures for this module.

@akrabat makes a good point above, I need to digest a little more before commenting.

@Thinkscape
Zend Framework member

getClosureConfig suggests it's all about closures, but I don't believe so. getTransientConfig is just a more profound way of saying getDynamicConfig ;-)

@akrabat Good point. I was about to point out bad performance of abstract factories. canCreateServiceWithName() is a bad idea, as it'll be expensive (looping and calling each abstract factory).

What would be much faster and easier is a probing function:

interface EnumerableAbstractFactory 
{
    /**
     * @return array
     */
    public function getServicesNames();
}

So basically when attaching an EnumerableAbstractFactory to a ServiceManager it loads up a list of service names and caches it internally, then it's just a hash lookup which is as fast as current invokator and specific-name-factories 👍

@akrabat
Zend Framework member

@Thinkscape but the "uncacheable" configs are all about closures. There is no other reason for them to exist as you should use getConfig() for everything else.

The "uncacheable" config methods are also a nuisance as they happen after config/autoload/* which cease to be easily understandable as the "winners" when in comes to config merging. This makes the explanation of how config merging works that much more convoluted.

I'm obviously in favour of improving the performance of abstract factories :) That's a separate RFC though.

@Ocramius
Zend Framework member

An abstract factory per module wouldn't be that hard to write. The canCreateServiceWithName() just needs to have an in_array() test against the list of services that you're able to instantiate and createServiceWithName is loosely a switch statement with one case for each service in the canCreateServiceWithName() list.

Just to make it more clear: we're not dealing with just the service locator(s) or closures.
The idea is to allow adding generally config that cannot be cached or that should be applied on top of cached config.

Other examples of why we need this instead of trying to hack around with abstract factories may be defining such a config:

'service_manager' => [
    'services' => [
        'supersecretstuff' => new \PDO('bat-cavern');
    ],
],
'world_end' => new \DateTime('2012-12-21'),

I don't think abstract factories solve the problem in any way, since they are a "fallback" solution. What we want to do here is also (eventually) overriding defined services.

I repeat: this is not just about closures and locators, but config in general

To be more clear, this should still be possible: https://github.com/EvanDotPro/EdpMarkdown/blob/a61cb4fc49efbd5c4285ba46a5286bfc78b0c938/Module.php

@marc-mabe
Zend Framework member

As noted above but more explained (hopefully).

The new config section will be merged AFTER config/autoload/* was merged. So get[Uncachable|Runtime|Dynamic|Transient]Config() doesn't describe the big difference but only a behavior that comes with.

Adding a new configuration method that will be merged AFTER config/autoload/* was merged is OK for me and also introduce caching between config/autoload/* and the new method.

So as @akrabat noted it's up to the user writing configurations using getConfig() to be cachable but a configuration section running after first merge could be a good idea imo.

@Ocramius
Zend Framework member

@marc-mabe a different config section could be OK, but then you'd have to call getConfig on every module anyways.

@akrabat
Zend Framework member

Just to make it more clear: we're not dealing with just the service locator(s) or closures.
The idea is to allow adding generally config that cannot be cached or that should be applied on top of cached config.

&

The idea is to allow adding generally config that cannot be cached or that should be applied on top of cached config.

This is a new feature then as we don't have that at the moment as far as I can tell. What we have at the moment are a set of getXxxConfig() methods allow configuration of various service managers.

To be more clear, this should still be possible: https://github.com/EvanDotPro/EdpMarkdown/blob/a61cb4fc49efbd5c4285ba46a5286bfc78b0c938/Module.php

That's possible by using getConfig(), but you would lose the ability to cache the merged config, so yes, if a two-class module is an anathema, then you have to have a getUncacheableConfig() type method.

@Maks3w
Zend Framework member

I agree with to have all config in a unique method but I totally disagree with split it by non semantic reasons.

Zend\Cache must be able to deal with the language specific types in a good way.

If you split by non semantic reasons you will obtain weird things like:

getConfig() {
  return array(
    'my_awesome_server_api' => array(
         'user' => 'admin',
         'port' => 8080,
    ) 
  )
}

// Some blank or non blank lines later and some overwrite of config inherited methods from other parent classes

getUnrelatedConfig() {
  return array(
    'my_awesome_server_api' => array(
         'host' => function() { return 'api.example.com'; },
         'password' => function() { return 'secret' },
    ) 
  )
}

Does not have sense from the point of design to have the config splitted along various methods without a logical nexus.
@Maks3w
Zend Framework member

Another fix: Zend\Cache could read the final config result and save cacheable methods in a cache storage and write the non cacheable keys in a temporal PHP file which will removed on cache reset.

I.e The fix must be supplied by the own framework component and not for the developer.

@stefanotorresi

@Maks3w 's one is quite the point! After all the config scattering was born from the cache problem, so rather than trying and fixing the config, fixing the caching itself would make more sense.

@EvanDotPro
Zend Framework member

@akrabat

Write your SM closures in getConfig() (i.e. module.config.php) and accept that you can't cache the config.

I get where you're coming from but with the concept of third party modules, I don't think this is a good idea. For example, I now have to refactor EdpMarkdown to be at minimum 2 classes or else anyone who uses EdpMarkdown is forced to disable config caching for their entire project.

👎 from me on the idea of getting rid of the uncacheable config concept.

@Thinkscape
Zend Framework member
@EvanDotPro
Zend Framework member

👎 on getClosureConfig(), too.

@Thinkscape but the "uncacheable" configs are all about closures. There is no other reason for them to exist as you should use getConfig() for everything else. '

Not entirely true. In some cases, it may be used for the services key as well, for actual instances: https://github.com/EvanDotPro/EdpMarkdown/blob/master/Module.php#L8

Edit: Sorry, I see @ocramius already pointed this out. Carry on. :)

@Ocramius
Zend Framework member

I'm actually getting to like the getTransientConfig() concept more and more. For example for things like:

[
    'report_timespan' => [
        'start' => new \DateTime('-1 month'),
        'end' => new \DateTime('+1 month'),
    ],
]

I think that's as good as a "transient" config example can get, and it's actually ok.

This is basically a concept of a piece of config that is mutable. I know I stated before that config should not be mutable, but this unlocks quite some possible development directions.

@texdc

@Ocramius Wouldn't that config be written without the DateTime instances?

['report_timespan' => ['start' => '-1 month', 'end' => '+1 month']]
@Ocramius
Zend Framework member

@texdc good point - I will need to think about that!

@Thinkscape
Zend Framework member

This is basically a concept of a piece of config that is mutable. I know I stated before that config should not be mutable, but this unlocks quite some possible development directions.

Like with the datetime example, keep in mind that many of those cases should be handled by callables (i.e. instances created on-demand of validators, services etc.). Similar to the diff between factories and services under SM config - factories and closures are cheap at definition time, expensive when calling, and you shouldn't instantiate anything unless you really need it. The more non-app modules keep doing that, the heavier the app will become and we loose the whole modularity advantage of zf :-|

@Thinkscape
Zend Framework member

Not entirely true. In some cases, it may be used for the services key as well, for actual instances:

@EvanDotPro maybe this should be split out then ? There's a difference between uncacheable config, cacheable config and not-a-config :-) This would give us 3 concerns instead of 2.

We could also think about calling it getServices(), which logically groups the kind of things that we have trouble with. Everything else is inherently cacheable and with little probability of containing closures.

@Ocramius
Zend Framework member

It's not just about services. Anything not cacheable would fall in here.

@EvanDotPro
Zend Framework member

getNotCacheableConfig()? Just thought I'd throw another one into the pool. I'm not really sold on it, just came to mind.

@stefanotorresi

I raise on getBareConfig() :p

@Thinkscape
Zend Framework member
@GeeH
@glen-84
There are only two hard things in Computer Science: cache invalidation and naming things.

-- Phil Karlton

What if you avoided this completely, by using an event listener, as we do for bootstrapping (onBootstrap).

If you want to use closures (or anything else that cannot be cached), you would implement the ConfigListenerInterface (onConfigLoaded). This would be triggered by the module manager and passed the merged (and usually cached) configuration.

From here you could make additional contributions to the configuration object as necessary.

@mschindler83

What about getPostCacheConfig() ?

@Ocramius
Zend Framework member

@mschindler83 very confusing for web developers...

@EvanDotPro
Zend Framework member

@glen-84

What if you avoided this completely, by using an event listener, as we do for bootstrapping (onBootstrap).

If you want to use closures (or anything else that cannot be cached), you would implement the ConfigListenerInterface (onConfigLoaded). This would be triggered by the module manager and passed the merged (and usually cached) configuration.

From here you could make additional contributions to the configuration object as necessary.

We already have an event for that, actually. However, it should not be used for this purpose, as any configuration provided via such a listener will not be overridden by global/local autoload configuration. IMO the global/local config files need to always the be "winners" of the entire merging process.

The primary use-case for the existing event is unsetting config keys that are defaulted by vendor modules (removing ZfcUser's routes for example), though I've seen a few other uses such as token processing, etc.

@Maks3w
Zend Framework member

We had a discussion at ZCEU about this:

I've explained my proposal of split cacheable and not cacheable config values iterating over the merged config and then store each one in the best storage possible (cacheable things in opcode caches and not cacheable things in a PHP file written in disk)
In successive runs of the app the config is retrieved from both sources (cacheable storage and not cacheable storage) and merged.

@Ocramius Notice the problem with the closures context (use keyword) may difficult to preserve in the non cacheable storage.

So we think that in source of the question config should be static values and there are no options for non cacheable things beeing the correct way for that use cases write a service with the aim of generate a dynamic config from static parameters (ServiceA inject ServiceAConfig)

We could add a trigger_error warning for non cacheable values so the user could be noticed when are not making a config in the correct way.

If I forgive something of our discussion please comment. /cc @Ocramius @EvanDotPro @akrabat

@Ocramius
Zend Framework member

No, that pretty much sums it up.

Current solutions:

  • Have a separate method for un-cacheable config
  • Don't support non-cacheable config (at all) - throw a meaningful exception while trying to cache config instead

The example with a special config key doesn't work at all anyway.

Right now I'd just suggest dropping all those get[A-Z][A-Za-z]+Config methods and that's it. No kind of support for non-cacheable config.

@bakura10

👍

@Ocramius
Zend Framework member

I wrote down the conclusions of the brainstorming I had with @Maks3w as well as what has been discussed here. That's what I'm gonna implement, so please read now or forget about it later on :-)

@Maks3w
Zend Framework member

👍

@samsonasik samsonasik referenced this issue in manuakasam/ZF2_3_QuickStart_Rewrite Mar 31, 2014
Open

PR Chapter 03 - Database and TableGateway implementation #10

@Ocramius Ocramius added this to the 3.0.0 milestone Apr 2, 2014
@GeeH GeeH added the To Be Closed label Mar 5, 2016
@GeeH

This issue has been closed as part of the bug migration program as outlined here - http://framework.zend.com/blog/2016-04-11-issue-closures.html

@GeeH GeeH closed this Jun 27, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment