In looking to revisit this code to use it in new places the design is being re-assessed, particularly driven by the experience of having written it the first time (which was more of an evolutionary process rather than a clear path).
I think Valerie itself can be shifted to be more focused on the features that it introduces. Specifically these are:
Providing richer feedback for rule violations themselves.
Allowing relatively independent rules to be applied against a graph
Of particular note is that Valerie does not introduce any value in terms of actually providing the rules
themselves which is a concern that is both fairly simple and for which there are readily available solutions.
Moving forward, therefore, I'd think this library can focus on adapting simpler predicate functions to
return ResultMaps, and providing the traversal mechanism which also handles that adaptation. The actual design for fitting this together can rely on lexical scoping...so any kind of providing of predicate
functions will basically not be supported at all in this library, but references to such functions should be available in an enclosing scope when they are used in rules, and passed to a method which will perform any necessary conversion. To complement this, Hamcrest will be used in current tests and can therefore serve as a suite of readily available predicate functions.
ResultMaps will be derived from adding some of the current "mold" concept into the EvalContext which would be merged with any data added during conversion (which would replace some of the current MOP usage). An existing Groovy usage could look like:
import static org.hamcrest.core.IsNull.nullValue
val.Idator.define {
has foo: { aver notNullValue(), msg: 'Foo must not be null', code: 'REQUIRED_FIELD' }
}
where code would be added to convert a Hamcrest Matcher for use in Valerie. The result of this shift would be that Valerie becomes a library which effectively enhances other libraries of tests rather than being a stand-alone framework itself.
In looking to revisit this code to use it in new places the design is being re-assessed, particularly driven by the experience of having written it the first time (which was more of an evolutionary process rather than a clear path).
I think Valerie itself can be shifted to be more focused on the features that it introduces. Specifically these are:
Of particular note is that Valerie does not introduce any value in terms of actually providing the rules themselves which is a concern that is both fairly simple and for which there are readily available solutions.
Moving forward, therefore, I'd think this library can focus on adapting simpler predicate functions to return ResultMaps, and providing the traversal mechanism which also handles that adaptation. The actual design for fitting this together can rely on lexical scoping...so any kind of providing of predicate functions will basically not be supported at all in this library, but references to such functions should be available in an enclosing scope when they are used in rules, and passed to a method which will perform any necessary conversion. To complement this, Hamcrest will be used in current tests and can therefore serve as a suite of readily available predicate functions.
ResultMaps will be derived from adding some of the current "mold" concept into the
EvalContextwhich would be merged with any data added during conversion (which would replace some of the current MOP usage). An existing Groovy usage could look like:where code would be added to convert a Hamcrest
Matcherfor use in Valerie. The result of this shift would be that Valerie becomes a library which effectively enhances other libraries of tests rather than being a stand-alone framework itself.