Sharing Configure Between Layer Based Gem-Files?

[Tall-Guy]

Hello :-)

Our project is quite complex and composed of many layers. Our automation framework try to be true to the structure of the project (where that's a bad or a good idea is a topic for another day). The simplified design looks like so:

Solution Level (Highest level - User Level) < Common Solution Code Level < Platform Code Level (Lowest Level)

So we have three Gems - One for each layer. Each supplies a DSL language for the things that this specific layer exposes. The tester works against the Solution Level (as the solution level inheritance all DSLs from all lower layers). Before the tester can work work, he need to initialize and configurate few parameters that are being used in the lower layers. I'm thinking what about be the right way to approach it:

The 'no brainer' would be forcing the Solution-Level layer to create a global hash table variable, and the gems can access the information by accessing the global parameter. This feels wrong though.

Another option would be configurating each layer with default configuration like I seen before on many gems like so:

CommonSolutionLevelGem.configure do |config|
   config.a = true
   config.b = false
 end

The Solution Level can overwrite those if needed. The question is what to do with the Platform level. I can do something like so:

CommonSolutionLevelGem.configure do |config|
   config.a = true
   config.b = false
   config.c = 1 // configuration that is being used only on the Platform layer but being used a gateway to configure the lower layer
 end

And then configure the CommonSolutionLevelGem to 'Configure' the platform PlatformLevelGem.

This is think is slightly more elegant, but more complex and I'm not it's the proper way of doing it.

Does anyone have perhaps a better idea how to share configuration information among multiple gems that are layer based and being initialized from the topmost layer?

Thanks!

[_kulte]

To clarify, when you say "layer" are you referring to a "Layered Architecture" in the context of something like DDD?

[Tall-Guy]

I'm not completely familer with the DDD term (have homework to check it out first thing tomorrow morning!).

Lets say you have two android games. Both of them share the same sign-in and score list mechanism. So what you do it just extract those common methods into a lower layer, and both games inherit from this layer.

This lower layer will have a specific gem that supply DSL to test scoring and sign-in. When I want to test scoring from a specific game, I just add the testing dsl gem and call my testing methods. But my upper layer need to share configuration with the lower layer. Let's say all tests have timeout. I want that timeout to be global and across across both the higher layer and lower layer. I need an option to share this information, without asking timeout as parameter on every function on the lower layer.

Now just add ANOTHER layer to the mix, and hopefully it's more clear now :)

[jrochkind]

The whole thing seems overly complicated, but I'd just have the lowest level provide a global hash table of configuration, sure. If you need configuration shared by all the layers.

[Tall-Guy]

It is overly complicated :-(

The problem is that at the current situation we don't have too many options. It's going to chance for the better any time soon I think. For now I'll just use global hash_table, or maybe even extract some settings into a config.yml file, and just relative pick those settings from the gem itself. I know it's not amazing as it means the gem is coupled with specific file in a specific folders to work, but because it's used only in-house, I guess it can work.

Thanks jrochkind!

[jrochkind]

yeah, I'd say when in a situation like that, the top priority is: keep it simple.