Re: [bv-dev] BVAL-265 - Expose settings defined in XML in the Configuration API
On 31 mai 2012, at 14:35, Hardy Ferentschik wrote:
* How do I interpret "typically the "META-INF/validation.xml file" -
typically implies an alternative. Is there is one how do I
differentiate between these alternatives? Shouldn't the docs read "Return
information stored in META-INF/validation.xml"?
When we discussed the feature, Sebastian mentioned
I mean could the potential configuration source be a different one in
the future, e.g. a
property file, a system property, some other non-XML config source.
This triggered the move away from XMLConfiguration to ConfigurationSource.
We can also imagine a specific provider offering an alternative source of configuration
and using this interface to expose it.
That was the rational behind the use of "typically".
* What do I return if there is no validation.xml? null? Or the class names of the
implementations default implementations?
Good question, I'm in favor of null. anyone against that?
* Last but not least, why ConfigurationSource? If I look at the class I see configuration
parameters so why not call this
(ValidationXml)ConfigurationParamters or (ValidationXml)BootstrapParameters.
"Source" implies for me that I can get information about
how the configuration was provided, e.g. XML vs programmatic.
I am not a big fan of ConfigurationSource either but that was the best we came up with. We
had XMLConfiguration before. I think I also proposed StaticConfiguration at some point.
I'm not sure ConfigurationParameters is truly accurate though. This interface
represents the content you retrieve from validation.xml today.
Is that merely parameters?
Technically this is the configuration but we already have a programmatic Configuration
object.
Ideas?
- XmlConfiguration
- StaticConfiguration
- ConfigurationSource
- ConfigurationParameters
- ?