struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gvanma...@comcast.net
Subject Re: Config inheritance
Date Wed, 30 Mar 2005 22:36:40 GMT
> 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.

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 <mrdon@twdata.org> 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: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> > 
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
> 


> 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 <mrdon@twdata.org> 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: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> > 
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message