Experimental loaders for the enorb library
enorb-exploaders to your
Then let bundler install it for you:
Alternatively you can also install it manually:
gem install enorb-exploaders
Currently available loaders
These loaders are currently available in the experimental track:
255.255.255.255, returns unaltered string or raises an error for invalid values)
You can use the loaders with enorb as demonstrated in this example.
require 'enorb' require 'enorb-exploaders' input = <<~DOC good-ipv4: 127.0.0.1 bad-ipv4: localhost DOC document = Eno.parse(input) document.field('good-ipv4', Eno::Exploaders::Ipv4) #=> '127.0.0.1' document.field('bad-ipv4', Eno::Exploaders::Ipv4) # raises an error "'bad-ipv4' must be an ipv4 address, for instance '192.168.0.1'.
Trying out new, innovative, cool and stupid loader ideas and seeing how they fit into real life usecases. Based on the findings they might be repackaged, integrated into the enorb core, or something else entirely.
Questions to explored
There could be a considerable amount of useful loaders, which all will require one or multiple error messages each - how can the translations for this be managed, versioned, updated, etc.?
From the insights gained with the core eno libraries it is safe to say that if there is to be some form of a shared translation repository, it should probably be shared by all (exp)loaders packages across different programming languages.
How should the loaders be categorized? Types (numbers, strings, ...)? Fields (IT, Communication, Geography)? Countries (International, country specific)?
How are the non-core loaders imported, accessed and used in applications? Should they be directly bootstrapped and usable like core loaders or should they remain more separate?
What kinds of loaders are actually sensible and useful to bundle for everyone, and where do we reach the limit of including too much bloat?