I find the before/after/only/except rules very hard to reason about by looking at individual YAML files. So you're saying this would be easier in your new approach?
We'll still need ConfigStaticManifest, right? Isn't that where most of the slowdown would be due to reflection (see existing Config implementation)?
My assumption is that happens rarely (since it needs a code deployment or env file change) - so wouldn't be a big problem in practice?
I can't see any tests about merging of false-ish values - doesn't look like that's implemented? The underlying array_merge is always overwriting with the values of later keys in its arguments.
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-dev+unsubscribe@googlegroups.com.
To post to this group, send email to silverstripe-dev@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
Is it worth talking about the pros and cons of the current config system? I've always felt the current system is trying to do too much and has made compromises to do so.Don't want to hijack the thread if the goal is just really performance based.
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-dev+unsubscribe@googlegroups.com.
To post to this group, send email to silverstripe-dev@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
HI Conrad,I agree with you that the config system currently does too much. My intention was to scale back/turn off some features by default, especially if they degraded performance. However, because the heavy lifting is being moved to the flush process this is less important. The features that still exist in my implementation are all commonly used features such as only/except/before/after.Of course, this doesn't talk about private statics but as Ingo mentioned this is more of a legacy feature that's still quite core to development.
On 25 August 2016 at 08:06, Conrad Dobbs <con...@webtorque.co.nz> wrote:
Is it worth talking about the pros and cons of the current config system? I've always felt the current system is trying to do too much and has made compromises to do so.Don't want to hijack the thread if the goal is just really performance based.
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
--
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-dev+unsubscribe@googlegroups.com.
To post to this group, send email to silverstripe-dev@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
----
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-dev+unsubscribe@googlegroups.com.
To post to this group, send email to silverstripe-dev@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
--Sam MinnéeCEOSilverStripe Limited
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-dev+unsubscribe@googlegroups.com.
To post to this group, send email to silverstripe-dev@googlegroups.com.
Is it worth talking about the pros and cons of the current config system? I've always felt the current system is trying to do too much and has made compromises to do so.
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
----
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
--Sam MinnéeCEOSilverStripe Limited
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
Then you'd want an API that the whole-config object exposes.- A way of asking that whole-config object for config settings of a given class- A way of asking that class-config object for a named config setting- With the option to for a given config setting to be inherited from parent classes, aggregated with parent class values, or uninherited.I think the whole-config object should conform to a nicely documented interface. This would pave the way for developers to build adapters to other config systems.
I prefer optimizing for developer speed and comprehension, not for CPU just for the sake of speed (unless it's obviously super-slow). Speed optimizations can be persued under the hood once we make things simple, compehensible and powerful for the developer.
> think this is a bad idea because it loads in unnecessary code on every pageview.No it doesn't. You can include this config file without the class even existing, and it will still execute as expected. ::class is a magic constant, which doesn't require the class to be in scope.
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-dev+unsubscribe@googlegroups.com.
To post to this group, send email to silverstripe-dev@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
Then you'd want an API that the whole-config object exposes.- A way of asking that whole-config object for config settings of a given class- A way of asking that class-config object for a named config setting- With the option to for a given config setting to be inherited from parent classes, aggregated with parent class values, or uninherited.I think the whole-config object should conform to a nicely documented interface. This would pave the way for developers to build adapters to other config systems.To SilverStripe the the config is a plain PHP array so it would be hard to separate it into objects with these properties. If something like this were to exist, it would exist as part of this package and output some kind of meta data that could be consumed.I prefer optimizing for developer speed and comprehension, not for CPU just for the sake of speed (unless it's obviously super-slow). Speed optimizations can be persued under the hood once we make things simple, compehensible and powerful for the developer.I disagree with this. This is the current state of the config system where developers and features were put ahead of performance. When you try to do that you end up adding magic and complexity for good developer UX and it becomes unmaintainable.This package takes both into account and I think balances correctly.DocumentationI've added some documentation to the git repo which visualises and talks about the architecture a bit. I'll add more detailing each transformer soon.
On 25 August 2016 at 17:54, Christopher Pitt <cgp...@gmail.com> wrote:
> think this is a bad idea because it loads in unnecessary code on every pageview.No it doesn't. You can include this config file without the class even existing, and it will still execute as expected. ::class is a magic constant, which doesn't require the class to be in scope.
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
I prefer optimizing for developer speed and comprehension, not for CPU just for the sake of speed (unless it's obviously super-slow). Speed optimizations can be persued under the hood once we make things simple, compehensible and powerful for the developer.I disagree with this. This is the current state of the config system where developers and features were put ahead of performance. When you try to do that you end up adding magic and complexity for good developer UX and it becomes unmaintainable.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-dev+unsubscribe@googlegroups.com.
To post to this group, send email to silverstripe-dev@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-dev+unsubscribe@googlegroups.com.
To post to this group, send email to silverstripe-dev@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
So while the before/after system is needed for some modules, the average SilverStripe dev shouldn't need it as often. It looks like the "folder priority" is already a fallback in Michael's solution: If two config blocks don't have before/after statements, they'd be merged based on the order in which the folders have been traversed (alphabetically?). Maybe if we made that fallback more predictable (choose project() last) devs would need to worry less about before/after?
The two items you mention dropping haven't been done yet, however I doubt we'd be able to drop inheritance. Most config calls use/expect inheritance
so dropping it would mean working everything out on the fly (at runtime) which is what i'm trying to avoid and what it currently does anyway.
Also, I think removing static config from extensions is the same as removing it from standard PHP classes. The ease for the developer is taken away, however having thought about how to solve this, its likely to be on the features that introduce a performance issue.
What are some examples of config settings that would be very confusing if inheritance was completely removed?
grep 'private static' framework/ -ri | grep -Ev '\$(db|has_one|has_many|many_many|allowed_actions)' | wc -l
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-dev+unsubscribe@googlegroups.com.
To post to this group, send email to silverstripe-dev@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
"I don't like YAML"I know some people out there don't like the yaml format, but I don't want to get into a discussion about that here. It remains that the entire SilverStripe ecosystem relies on it and there's already a vast amount of changes coming in SS4. If you don't like yaml, this package might be the first step to replace it but that is not its intention.
"Private statics for config are really just a legacy hack in my opinion, and should be replaced by components which are initialised with constructor args and setters through dependency injection parameters configured in YAML"
Given that $db, $has_one, etc are handled be the config system, I disagree with Ingo's view quite strongly here, at least for SS4. The level of refactoring needed in the ORM and Controller systems would be massive. I'm not convinced that the end result would be better for developers, and it would probably be less work to remove our own ORM and replace it with another implementation.
This functionality is required but it could be handled by having DataObject say "give me the db property of the current class and that of any extensions applied to it" rather than relying on the config system to do this magically. In addition to db properties, allowed_actions is the other place where this gets used. So perhaps we could do away with this, which would mean we could drop the EXCLUDE_EXTRA_SOURCES option too.
YAML Inheritance
In regards to the multiple inheritance comments there is some way for YAML already to re-use yaml values in the spec. I'm not sure whether symfony/yaml supports it and I don't think we'd be able to use it across files or with complex structures anyway. There's some details here: http://yaml.org/spec/1.2/spec.html (see 2.2 Structures)
Alternatively we could just add an 'extends' header but this adds quite a lot of complexity. It does keep the meta data in the header and out of the content though.
- A debug view showing the "final" config tree (as cached by the system). We'll have to add a disclaimer that it excludes any execution path specific Config::inst()->update() calls though.
- Tracing from which YAML file or PHP class a particular value in the config tree is set
--
You received this message because you are subscribed to a topic in the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/silverstripe-dev/q5khashNiuY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group and all its topics, send an email to silverstripe-dev+unsubscribe@googlegroups.com.
To post to this group, send email to silverstripe-dev@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-dev+unsubscribe@googlegroups.com.
To post to this group, send email to silverstripe-dev@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-dev+unsubscribe@googlegroups.com.
To post to this group, send email to silverstripe-dev@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
Hey Flo,I've been integrating it with SilverStripe and I have it pretty much working. Still got some work to do to performance test it and there's a few things not quite there yet but making good progress.Whether it will be in SS4 or not? I'm not sure but that's i'm hoping.I'm using PSR-6 cache in my implementation so this is probably blocked by the PSR-6 RFC anyway.
On 15 November 2016 at 15:51, Florian Thoma <floria...@innoweb.com.au> wrote:
Hi Michael,
What is the status of this? Is this going to go into SS4?
Cheers, Flo
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-dev+unsubscribe@googlegroups.com.
To post to this group, send email to silverstripe-dev@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
I agree with everything you say.
We are now dependant on that config system. There will always be some sort of a config, whether that’s private statics, constants, yml or XYZ doesn’t really matter.
Your example works fine if you develop all modules yourself, but we need a way to handle API keys for other modules too, like payment etc.
We know, that a lot of modules use the yml config for the API keys.
We also know that the API keys can’t be in the code base of the project.
And we now also know that just adding a env.yml thing is not secure either.
As I mentioned before, I currently use a modified version of https://github.com/silverstripe/silverstripe-framework/blob/3.4/core/Constants.php#L36-L77 in mysite/_config.php to load a custom PHP config file where I use Config::inst()->update() to add/modify the settings for the environment. Not the most performant solution, but it works.
What would be your suggestion to solve this?
Cheers, Flo
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-dev+unsubscribe@googlegroups.com.
To post to this group, send email to silverstripe-dev@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
Thanks, Michael! ;)