Refactoring configuration

I'm going through an interesting refactoring that I'm doing using roles (my first time) and I'd like to summing up what I'm doing in this blog.

I think that an important feature of Strehler is the possibility to manage custom entities, custom "database tables" that can be manipulated through Strehler backend using all the features Strehler makes available.
New entities can be easly (I hope) added as said in this tutorial, but to give enough freedom to developer, as you can see, there's a lot of flags available in Strehler configuration to change the behaviour of the entity itself.

The actual problem is that not only new custom entities need values for those flags, but also standard entities: Article, Image, User and Log and they can't just use all the default values. Log, for example, is not creatable or editable, it's interface has to be read-only while Article, Image and User allow a complete CRUD flow.
Big question is: where configurations for them are?

Solution until Strehler 1.1.8 is horrible. I've and horrible method (see it here) that fetch informations from config.yml and assign hardcoded values for standard entities.

This solution has, in my opinion, two problems:

• It's in the wrong place. Six months from now I'll never think that Article configuration is in a curious Strehler::Helper packages package.
• Makes config.yml the only way to configure entities. Flags are A LOT and many configurations can make this file a real mess.

This is the reason I'm introducing a role consumed by Strehler::Element where every parameter is a method returing, with no input parameters, the value of the flag itself. Standard implementation of every method is just a little piece of code reading from config.yml, as in Strehler::Helper.

Why is this solution better? Because is... more object oriented and allows me (and Strehler developers) to keep informations about entities in the entity class, where they should be. 

So, for example, Article parameters doesn't need no more an external method in a strange place. They're just in Strehler::Element::Article, an override of the standard methods where fetching from config.yml is replaced by returning just the hardcoded value... hardcoded in the right place.

This way, a Strehler developer creating a custom entity can now choose between write down all the configurations in the config.yml or just leave in config.yml minimal configuration needed and add all the parameters in the custom class.

I think that both methods should be used: config.yml when a flag can change through time or in different environments, class methods when a parameter is... "endemic" for the designed entity.

I talked about methods and not attributes because in many cases I need to know class configuration, without an instanced object. Is the same logic of the metaclass_data method.

I hope to release this new configuration soon!