Propose new setting types
vinistock opened this issue · 4 comments
Description
The idea of Sail is to be a centralized source of live configurations for Rails applications. More setting types can make the configurations simpler and require less application code to be written.
Request
Propose new types of settings that could be useful having in Sail. Your proposal can either be a written idea as a comment in this issue or as a pull request implementing the new type.
Existing types can be found in the readme.
@vinistock This is an interesting gem (project) that you started.
Just a thought: How about Date
and Hash
types?
Datetime or date configs would be ideally string configuration but I am wondering if it can be directly converted to Date
or DateTime
For Example:
TIMEAGO_DATE_TIME_FORMAT = "1 January 2000 at 12:30 PM"
NOTE_DATE_TIME_FORMAT = "Jan 1, 2000 @ 12:30pm"
KALENDAE_DATE_FORMAT = 'Apr 12, 2000'
And hash
configurations type could be
SOCIAL_NETWORK = {
'evernote' => 'Evernote',
'google_oauth2' => 'Google',
'facebook_oauth' => 'Facebook'
}
@rohandaxini thanks for your interest in the project and for your suggestions!
The Date type should be pretty straight forward. You can just parse the string and it will throw an ArgumentError if it isn't valid. I think it will be a great addition.
About the Hash type: can you expand on possible use cases for this? What kind of live setting would be controlled by a Hash type? Furthermore, how do you picture this in the code? Keep a JSON string in the database and then parse it?
The only current limitation would be that the value field is a regular string and not text, which could not be enough to represent some hashes.
The Hash suggestion is also very interesting, I'm just trying to fully understand it.
Date
type
Thanks for accepting my recommendation to add Date
type. Yeah, that's correct, parse the string and throw ArgumentError
if is its invalid. I can raise a PR for same. I think ill need to just make a change in this file https://github.com/vinistock/sail/blob/master/app/models/sail/setting.rb
and in the documentation. Is that correct?
Hash
type
Let's say we have a CSV or Excel to parse and import. We might want to map certain columns (attributes) of this CSV and import it to application specific columns based on users need or configured needs. This kind of mapping would be easier through a hash configuration. For example
ABCD_IMPORT_MAPPING_HASH = {
'Abcd Title' => 'abcd_title',
'Abcd Use with' => 'abcd_use_with_name',
'Abcd Tags' => 'abcd_tags',
(Here Abcd
represents some domain specific name)
The only current limitation would be that the value field is a regular string and not text, which could not be enough to represent some hashes.
Yeah, that's a challenge.
Date type
Feel free to open a PR to implement this. I'd be glad to have your contribution in the project.
The steps to achieve it are as follows:
- Add the new cast_type to Setting
- Add a validation to prevent saving invalid date strings to the database. Something like this will do
def date_is_valid
DateTime.parse(value)
rescue ArgumentError
errors.add(:invalid_date, 'Date format is invalid')
end
- In value_cast.rb, create date_get and date_set methods. The date_get method should return a DateTime instance, so you will need to parse the string stored in the database here again. The date_set will simply return the regular value (validation will perform the checks)
- Add the new type to readme. It should be included in the types list and there should also be an example
- Don't forget the specs in setting_spec.rb (there should be new examples for the validation, for get and for set)
Hash type
I'm still unsure how to implement this with the string size limitation. Initially, I wouldn't like to change the value field to text.
Perhaps we can come up with a clever shorter representation of hashes that can be internally converted by Sail into a real Hash? If you have an idea on how to implement this, you can also created a separate PR for it. The steps should be the same as the Date type, however, validations, and get and set casts will be more complex.