MidCOM configuration stack
-
Henri Bergius
MidCOM configuration stack
Fri July 17 2009 12:15:10 UTCHi, all
Before we slowly start freezing Mjolnir APIs, I'd like to introduce
another API change to Midgard MVC: configuration stack.
As you know, templating in Mjolnir already follows the stack model,
meaning that all templates are loaded from a single namespace, with
components being able to override templates coming from higher levels
of the stack.
Template stack looks like the following:
* Stacked components (midcom_core etc)
* Current component
* Midgard style elements
* Midgard page elements
This is great as then any component can for instance override the
error template.
I'd like to do the same for configuration. Currently configuration is
loaded from stack, but with each component providing its own stack:
* Component config
* Configuration snippets
* Page configuration
Instead, I'd make MidCOM configuration service combine all
configuration into a single stack. This means a loaded component could
change midcom_core configurations also if they want to.
Component-specific configs can be handled by having namespaced
configuration keys (as we do with templates).
In this case, the configuration stack would be:
* Stacked components (midcom_core etc)
* Current component
* midgard_config file
* Configuration snippets
* Page configuration
This way things dealing with the installation (setting MidCOM cache
directory for instance) can be loaded from the current midgard_config
instead of having to edit snippets.
It also means components loaded to the stack can inject their own
routes into the route definitions. This is very useful as then
components can add their own administrative UIs easily to the site. In
current system we do this merge already, but only for routes defined
by midcom_core and the current component.
--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/
Skype: henribergius
Jabber: henri.bergius@gmail.com
Microblog: http://www.qaiku.com/home/bergie/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
Re: [midgard-dev] MidCOM configuration stack
Fri July 17 2009 18:55:07 UTCHenri Bergius writes:
> Hi, all
Hi!
> This way things dealing with the installation (setting MidCOM cache
> directory for instance) can be loaded from the current midgard_config
> instead of having to edit snippets.
midgard_config is not propagated from connection, so it's not available
if implicitly (Apache) initialized.
We didn't clarify what to do with this issue.
In this particular environment (Apache) we need to expose sensitive data
then.
Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
Re: [midgard-dev] MidCOM configuration stack
Sun July 19 2009 13:45:34 UTCHi,
On Fri, Jul 17, 2009 at 9:53 PM, Piotr Pokora<piotrek.pokora@gmail.com> wrote:
> midgard_config is not propagated from connection, so it's not available
> if implicitly (Apache) initialized.
Well, that wasn't the core part of the idea of a configuration stack.
If we can't use midgard_config to this, Midgard MVC can have its own
file. This might be better anyway as Midgard uses INI syntax and MVC
uses YAML syntax for configuration.
> Piotras
/Henri
--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/
Skype: henribergius
Jabber: henri.bergius@gmail.com
Microblog: http://www.qaiku.com/home/bergie/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
Re: MidCOM configuration stack
Mon November 30 2009 18:17:39 UTCHi,
I'd make MidCOM configuration service combine all configuration into a single stack. This means a loaded component could change midcom_core configurations also if they want to.
This is now done: http://trac.midgard-project.org/changeset/24261
A lot cleaner API, better injection support, and about 10% performance improvement (which will be easy to beat by adding config cache, the array merges we do there are expensive).
/Henri
