In a lot of cases, we do have null values. In most (if not all) of
those cases, a null value is used to test for the presence of a value
and affects behavior. For instance, let's take the "attribute"
property for an action mapping.
<action path="/base" attribute="customAttr" name="myForm" type="..."/>
<action path="/sub" extends="/base"/>
/sub can't be configured to stop using "customAttr". The closest we
can get to allowing the user to specify null would be an empty String.
We can put in code to check for these in the getters, and treat them
as null, but I'm not yet comfortable with that. I don't know if we
have any attribute out there where a value of an empty string makes
sense; if there are, then treating empty strings as nulls would cause
a compatibility problem. (I think it's technically valid to use an
empty string as an attribute name.)
In some cases, the default values are hardcoded when a property is initialized:
protected String scope = "session";
The inheritFrom() method then uses this value to see whether it should
inherit a value from a base config:
if (getScope().equals("session")) { // check if scope was
not specified
setScope(config.getScope()); // use value from base config
}
Cases like these could be changed so that default values are only
assigned when configuration is frozen. However, that will only work
for properties that have non-null default values.
Hubert
On Wed, 30 Mar 2005 12:23:01 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
> That is an interesting problem. We had a similar problem with
> unmarshalled XML using JAXB. We had an optional number field, but found
> if we unmarshalled that into an int, we had no way of telling it was
> defined or not. We ended up using Integer or BigInteger so at least we
> could tell if it was null. Perhaps we could use the wrapped primitives
> for config as well, in addition to primitives. Ugly, but at least we
> could tell if something is defined or not.
>
> Don
>
> Hubert Rabago wrote:
> > Updated diffs, if anyone is interested, are in
> > http://www.rabago.net/struts/configinheritance/ .
> > If anybody gets a chance, please take a look, ask questions, make
> > suggestions or comments. If I don't hear from anybody in a couple of
> > days, I will go ahead and commit these changes.
> >
> >
> > Known limitation:
> >
> > A "sub" config cannot override a "base" config's property in order to
> > revert to a default value.
> >
> > In the code that inherits configuration, I check if a property has
> > been set or not. If it hasn't been set, I inherit the value from the
> > base config. The way I check is by comparing the value against the
> > known default:
> >
> > if (getType() == null) {
> > setType(config.getType());
> > }
> >
> > This means that as long as the base config provides a value for a
> > property different from the default, the sub config cannot use the
> > default value for it. For another example, if a forward named
> > "success" is extending another forward named "home", and "home" has
> > redirect="true", "success" cannot be defined such that
> > redirect="false", due to code like this:
> >
> > if (!getRedirect()) {
> > setRedirect(baseConfig.getRedirect());
> > }
> >
> > Of course if you can help overcome this limitation, I would appreciate it.
> >
> >
> > Hubert
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
