Courier Context should not be config, use a code based discovery

[edurenye]

Courier Context should not be config, use a code based discovery, otherwise if for example we have it set in config and we want to add a new token we will need to add an upgrade path.

[mirodietiker]

With code based discovery we mean either use annotation or a hook.

Please elaborate on why the context is currently a config to allow us understand the use case / value.

[dpi]

Overall you are probably correct. CC should be a hook/registry system. But other than the need to re-implement, what benefits do you aim to gain from doing this?

Are you planning to add additional metadata to the contexts?

[mirodietiker]

It's about the severe problem Eduard described:

I start with a mail containing one token. As a module i would thus provide default config to register the context to have it installed.

Then i learn that i need to extend tokens for that context. I extend the code with the new context. I would expect that after flushing the cache, the token can be used. But no, i need to provide an update function to update the config based context. That's source for many pain points in maintenance and agility in mail management. Adding a new token is a common operation.

[dpi]

Good answer :+1:

[dpi]

I have left out context from #30 until we decide how to proceed with this issue. Fortunately you still automatically get site-wide and identity contexts for global template collections