> > 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.
>
>
> I was just lurking about and wanted to share an approach that we used doing a
> similar thing as a struts extension/ plug-in. For primitive types we created
> a
> boolean attribute to represent the "nullable" or unset state, the default
> being
> true. The setter would toggle off the flag. The boolean flag was used when
> resolving inheritance.
>
> private boolean doubleSpace = false;
> private boolean doubleSpaceIsNull = true;
>
> We also had to add some logic on startup to make sure there were not any
> circular inheritances.
>
> I think that I've posted this DTD link several times
> http://www.sos.state.co.us/dtd/strtus-extension.dtd.
Opps, http://www.sos.state.co.us/dtd/struts-extension.dtd
>
> Added inheritance to the struts metadata will be a really nice feature.
>
> Gary
>
>
> >
> > 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]
> >
>
>
> > 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]
> >
>
> ---------------------------------------------------------------------
> 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]
