You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Framework configurations are a fast moving target.
With the current approach, if we introduce a new setting in a minor release of Model/View/Controller gems, we're forced to add it to Lotus::Configuration as well.
There are some configurations that makes sense to expose at the top level (Lotus::Configuration) like we do right now. Settings like adapter and mapping are stable in both Lotus and Lotus::Model.
There are also some minor things that we can add from time to time.
For instance, in the next version of Lotus::Controller there is Action#request_id. It's implemented like this: SecureRandom.hex(DEFAULT_REQUEST_ID_LENGTH). That constant is equal to 16.
Now, if some reason we want to add way to change the algorithm or the length, via Lotus::Controller::Configuration, we can't think to add the corresponding API in lotusrb. Again, the reason is the maintenance in the long term: it's hard to keep in sync Lotus with the other frameworks.
My proposal is to add per framework configuration.
The idea is to forward those method calls to the underlying frameworks configurations.
Getting back to the example above, if we ship a minor release of lotus-controller with that setting. Once the developers do a bundle update they're able to use it, without the need of a new lotusrb release.
The text was updated successfully, but these errors were encountered:
Framework configurations are a fast moving target.
With the current approach, if we introduce a new setting in a minor release of Model/View/Controller gems, we're forced to add it to
Lotus::Configuration
as well.There are some configurations that makes sense to expose at the top level (
Lotus::Configuration
) like we do right now. Settings likeadapter
andmapping
are stable in both Lotus and Lotus::Model.There are also some minor things that we can add from time to time.
For instance, in the next version of Lotus::Controller there is
Action#request_id
. It's implemented like this:SecureRandom.hex(DEFAULT_REQUEST_ID_LENGTH)
. That constant is equal to16
.Now, if some reason we want to add way to change the algorithm or the length, via
Lotus::Controller::Configuration
, we can't think to add the corresponding API inlotusrb
. Again, the reason is the maintenance in the long term: it's hard to keep in sync Lotus with the other frameworks.My proposal is to add per framework configuration.
The idea is to forward those method calls to the underlying frameworks configurations.
Getting back to the example above, if we ship a minor release of
lotus-controller
with that setting. Once the developers do abundle update
they're able to use it, without the need of a newlotusrb
release.The text was updated successfully, but these errors were encountered: