On 5/25/05, Riyaz Mansoor <[EMAIL PROTECTED]> wrote:
>
> just a thought.
>
> ie, not expose the "properties" object (as it is) by the
> getProperties,setProperties methods.
I'm not sure I want to forbid config subclasses from accessing
their properties directly. I've come across several libraries
and frameworks which used "private" all throughout and made it
difficult if not impossible for me to customize certain behavior.
(I'm still running into those issues with the app I inherited
here in my day job.)
The 'properties' field was initially declared as protected when
it was only in ActionConfig. The goal was to reduce the likelihood
that subclasses would be needed. Now that it's in a class that's
intended to be subclassed, I wonder why it became private. Joe?
> by my last viewing of the Config
> classes, only ActionConfig uses "properties" and needs to change for
> this - not much.
We also need it in FormBeanConfig.
> get/setProperties can be replaced by
>
> void inheritProperties(childConfig) {
> // for each "xx" property in (parent) class
> // if childConfig.getProperty("xx") == null
> // copy the arbitrary property
> }
>
>
> imho, i think this is a good way to do this, provides separation between
> BaseConfig and its extending classes
BaseConfig already has an "inheritProperties(BaseConfig)" method, doing just
what you've outlined. This is used by subclasses when extending another
config object, not to be confused with the need to "copy" another config
object, which is when ActionConfig and FormBeanConfig needs access to the
properties field.
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
