Improving configuration process

[Alessandro Molina]

Just writing to get some feedbacks.

It looks to me that the configuration process in TG2 is the framework part that requires most improvements. Some of its complexity is due to the need to cope with Pylons, PasteDeploy and TG options.

The first issue that bothers me is how @expose and AppConfig.renderers interact. The first requires renderers to be in place to check if the exposed template engines are available. This forces users to create AppConfig before importing or declaring any controller. Otherwise renderers detection gets totally disabled. This is not much of an issue usually, as the quickstart is organized that way, but is pretty obvious when using minimal mode.

The other issue is the complexity derived from how init_config works.

It is not clear when options get available or where the user is supposed to set custom options.

Some options have precedence when set in AppConfig, while other have precedence when set in .ini also the after_init_config hook is not explicitly suggested to extend configuration with custom options.

Any idea on how to tackle those? The most simple solution would be to leave the current behavior but at least notify the user: Raising an exception if no renderers are available when declaring/importing the controller telling the user to do it after setting up the configuration and explicitly stating the after_init_config is the place where to add custom configuration options.

[Moritz Schlarb]

Since I struggled with that lately, too, I appreciate all kind of improvement, although I now know my way around :D

My 2 cents atm:

Why is it strictly required for @expose to know about the renderers? Couldn't that be done more lazy when they are first used?

For init_config, there was one thing that helped me a lot after having no success, and we should definitely document it somewhere:

In any hook, or in after_init_config, or really anywhere, it can be very helpful to  import tg.config as tgconf in the scope of the function and not globally in app_cfg.py!

[Alessandro Molina]

On Fri, Jul 12, 2013 at 3:19 PM, Moritz Schlarb <mosc...@metalabs.de> wrote:

Since I struggled with that lately, too, I appreciate all kind of improvement, although I now know my way around :D

My 2 cents atm:

Why is it strictly required for @expose to know about the renderers? Couldn't that be done more lazy when they are first used?

Up to now I have actually two branches on my local repo that try to do that, but both of them don't satisfy me due to various reasons.

I'll give a third try, I have an idea for a more flexible solution and that should not slow down too much things, but it won't go in 2.3 stable as it is too big change between a beta and a stable.

 

For init_config, there was one thing that helped me a lot after having no success, and we should definitely document it somewhere:

In any hook, or in after_init_config, or really anywhere, it can be very helpful to  import tg.config as tgconf in the scope of the function and not globally in app_cfg.py!

That is another thing that confuses people a lot. Both base_config and tg.config contain configuration options, but they do it partially and at different times.

I think we should at least document the proper way to do that. Sooner or later some refactoring to make it more clear will be required.

[Alessandro Molina]

On Sat, Jul 13, 2013 at 9:16 PM, Alessandro Molina <alessand...@gmail.com> wrote:

On Fri, Jul 12, 2013 at 3:19 PM, Moritz Schlarb <mosc...@metalabs.de> wrote:

Since I struggled with that lately, too, I appreciate all kind of improvement, although I now know my way around :D

My 2 cents atm:

Why is it strictly required for @expose to know about the renderers? Couldn't that be done more lazy when they are first used?

Up to now I have actually two branches on my local repo that try to do that, but both of them don't satisfy me due to various reasons.

I'll give a third try, I have an idea for a more flexible solution and that should not slow down too much things, but it won't go in 2.3 stable as it is too big change between a beta and a stable.

I'm quite satisfied with how the third try at solving the issue is coming out. Maybe this is the right one.

The current solution provides support for "configuration milestones". 

When a feature of TG depend on the availability of parts of the configuration it can register for milestones.

Whenever a milestone is reached all the registered entities are notified and can proceed with their configuration.

If the entity registers for a milestone that is already passed it's immediately notified and proceeds like before in synchronous manner.

Suppose you need to perform something that depends on the available template engines (like tgext.admin that changes template depending on the default renderer), you simply register for renderers_ready milestone and whenever is reached you are notified an can perform your own setup.

Normally due to the way TG applications and pluggables are setup, every milestone is already passed before any controller is imported, so nothing changes practically since before.

On the other side custom extensions and minimal mode applications can import controllers at any time which would lead to issues before milestones were available.

I'm going to push this on config_milestones as soon as I get back to 100% coverage, any feedback will be appreciated!