Stephen McConnell wrote:
>
>
> Berin Loritsch wrote:
>
>> I see nothing wrong about the Parameters package as a general rule, just
>> a
>> couple questions:
>>
>> 1) Do we want to decouple the Parameters interface from the Parameters
>> object
>> like we do with Configuration?
>
>
> Advantage - alternative implementations.
> Disadvantage - implemetation change on Parameters instance creation.
> The advantage is nice in principal but does is justify a change that
> will impact existing code. Based on the projects I'm aware of - the
> change would be very minor.
> +0.5
>
>>
>> 2) Are we going to explicitly declare Parameterizable and Configurable
>> as mutually exclusive?
>
>
> Minor correction in terminology.
> Parameterizable and Configurable are currently declared as mutually
> exclusive. Tghe question is, "are we going to enforce this", "relax
> this", or "ignore this"?
>
>> As to #1, it would provide consistency and provide a nice way of making
>> different implementations of the parameters object. It would also
>> encourage us to place the Parameters.fromProperties() and
>> Parameters.fromConfiguration() methods into a ParameterUtils class.
>>
>> I am +1.
>
>
> I'm leaning in that direction.
>
>
>> As to #2, I believe that is what we intended to do in the first place.
>> The problem is that there is no way to programatically enforce it
>> without the ContainerUtils or some other helper class. If it is
>> mutually exclusive, we have to specify that in the javadocs --and say
>> that if a component extends Configurable and Parameterizable the
>> result is undefined.
>
>
> +1
>
>> Something like the text below:
>>
>> "WARNING: The Parameterizable interface is mutually exclusive of the
>> Configurable interface. If your component extends both of those
>> interfaces, the behavior is undefined.
>
>
> That is sufficient.
>
>> The container is free to throw
>> an exception and refuse to use your component, or to pass an object
>> in to both methods. The object may be empty. In short do not mix
>> these two interfaces in your components."
>
>
> Above detail is going into too much detail (suggesting what may happen).
> Declaring that the behavior is "undefined" is sufficient.
>
> The question of a common approach to handling this situation by
> containers would be desirable. I'm differentiating here between generic
> contains and custom contains. Custom contains should be able to mix and
> match both because the custom container knows more about the components
> it is managing. However, generic contains (Phoenix/Merlin/ECm/Fortres)
> should attempt to take uniform approach. Possibilities include:
>
> 1. reject the component at validation stage (nasty)
> 2. apply configuration and bypass parameterization (preferred)
> 3. apply parameterization and bypass configuration
> 4. apply both (inconsitent unless we have a consitent approach to
> identifying a parameter description (XML) from a configuration).
>
Or, in the case of a mixed case, the parameter object could come from
<classname>.properties - which would be a workable solution in that it
would eliminate the issues of paramters derived from configuration info.
Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
