Move configuration into an 'more rails way'

[alexanderadam]

Move configuration into an 'more rails way'

[fpellanda]

Maybe we should do it the "Rails" way. Rails does not use yaml files for configuration... Why yaml?

[alexanderadam]

Well. The database.yml for instance is a well known example of yaml used for configuring rails apps.
Even external stuff like travis or rubocop use yaml for configuration.
I don't think that yaml is so bad at all. 😉

Initializers or something else which leads to 'normal' keys in the config also would be fine in my opinion.
But the also would result into large code-bases that contain configuration anyway.

[fpellanda]

Yes, right. Rails uses YAML. But I meant the configuration for gems.

I don't know what you want to configure, I just want to prevent implementing the configuration mechanism twice - when we realize that YAML is not enough.

I mean, I don't know a gem that uses yaml files for configuration. Do you?

[alexanderadam]

kuhsaft is an engine which is basically a rails app anyway. 😉

But sure, as I already mentioned for example rubocop and travis.
I could image something like this which could be set in the rails instance to overwrite some kuhsaft defaults

asset_brick:
  styles: 'pdf word excel button'
  user_can_add_childs: false
  renders_own_childs: true
  allowed_brick_types: '$inherit'
  allow_voda: true

As I've said already: that is really just my personal preference.
I have no problem to use something different if yaml files aren't an adequate solution.
I just find the current mix of business logic and configuration not optimal - that's all. 😉

[fpellanda]

So

configuration_implementation:
  yaml: +1
  ruby: +1

Other votes? ;)

[effkay]

@alexanderadam @fpellanda I generally am in favor of extracting configuration and separating it from business logic. Going all the way would mean yml files and I have no objection to that. So 👍 for a yml file!

[manufaktor]

TLDR: keep it in ruby land :)

My 2 cents:
The underlying issue here is the de-separation of model and view-model which was - at the time we built this - simply a shortcut we took to make it useable. Imagine you'd build the inputs strictly client side, you'd essentially have a client model handling all of this.

Imho allowed_brick_types: '$inherit' is a smell you're eventually going to invent a yml dsl here. Also I don't believe it's true the values are not going to change in the app lifecycle. The initial imagination was that certain options can be data/context sensitive, for example: don't let users add childs when there's already 5 childs attached. This is certainly easier to extend in ruby land than via yml configuration.

FYI these are use cases I'm evaluating for the current project I'm working on.

[effkay]

@manufaktor good ponts, thanks a lot for your input! The context sensitive options are indeed a nice idea, though I don't think we used them a lot. Are you suggesting a split between brick models and brick view models?

[manufaktor]

@effkay basically I'd just delegate the options in question to a config object with some sane defaults. You could also go the decorator route, all I'm saying I'd prefer not to have YML (You could always add that to back the config objects but I'm sharing @fpellanda 's concerns).

[effkay]

Migrated / Added to qBrick roadmap: https://github.com/screenconcept/qbrick