Re: [bv-dev] BVAL-292 / BVAL-293 ConfigurationSource rename and behavior clarification
On Jul 17, 2012, at 10:42 PM, Gunnar Morling wrote:
> Initially I thought about using DefaultConfiguration as an
alternative name, but as Emmanuel pointed out in an earlier email it clashes to a certain
degree with the programmatic Configuration interface.
But does it really clash? IMO Configuration provides a unified way for
accessing the effective configuration. It allows to change the
configuration in a programmatic way but it could also provide a handle
to the default configuration from validation.xml via
getDefaultConfiguration().
I see there is a clash with getDefaultMessageInterpolator() etc,
though (which returns the default implementations as demanded by the
spec.), so maybe the method returning the user provided default
configuration should be named getExternalDefaultConfiguration(),
getBootstrapDefaultConfiguration() or similar.
That's exactly the clash I am talking about. If we call it _DefaultConfiguration_ and
just call the getter
Configuration#getDefaultConfiguration we have for example
Configuration#getDefaultMessageInterpolator, but
also Configuration#getDefaultConfiguration()#getMessageInterpolatorClassName. IMO that can
be misleading.
One way to avoid this would be to call the accessor #getExternalDefaultConfiguration() or
#getBootstrapDefaultConfiguration()
as you suggest, but then I rather call it BootstrapConfiguration to begin with.
I chose XMLConfiguration, because I think it is ok to limit this method to validation.xml.
If we really want to keep
"doors open" I could imagine renaming to BootstrapConfiguration.
What do others think?
--Hardy