You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Hubert Rabago <hr...@gmail.com> on 2005/03/30 05:16:20 UTC
Config inheritance
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
Re: Config inheritance
Posted by Hubert Rabago <hr...@gmail.com>.
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 <mr...@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
Re: Config inheritance
Posted by Don Brown <mr...@twdata.org>.
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
Re: Config inheritance
Posted by Joe Germuska <Jo...@Germuska.com>.
At 7:13 AM -0600 3/31/05, Hubert Rabago wrote:
>"subForm" can no longer just provide the minimum required when
>overriding/extending properties. It either specifies the form
>property fully, or accepts what the base config provides it. This
>would make it consistent with how <action>s deal with <forward>s and
><exception>s.
>
>Comments appreciated.
+1 I like consistency.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Config inheritance
Posted by Hubert Rabago <hr...@gmail.com>.
> -----Original Message-----
> From: Joe Germuska [mailto:Joe@Germuska.com]
> Sent: Wednesday, March 23, 2005 12:41 PM
> To: Hubert Rabago; Struts Developers List
> Subject: Re: Adventures with configuration inheritance
>
> I disagree with this interpretation. For what it's worth, my
> assumption would be that any named ForwardConfig in an extended
> ActionConfig would override, not extend an identically named
> ForwardConfig in the parent ActionConfig.
<snip/>
>
> By my interpretation, the /someOtherPath forward named "subForward"
> would have no relationship to "/somePath"'s forward named
> "subForward".
I'm thinking of applying the same logic for form properties. This
would make it more approachable, and reduce the areas where the user
can't use default values because a base config has specified a value
for them. Going back to the earliest example I used:
<!-- the form I extend -->
<form-bean name="baseForm"
type="o.a.s.a.DynaActionForm">
<form-property name="firstName" type="java.lang.String"/>
<form-property name="lastName" type="java.lang.String"/>
<form-property name="score" type="java.lang.String"/>
</form-bean>
<form-bean name="subForm"
extends="baseForm">
<form-property name="score" type="java.lang.String" initial="100"/>
<!-- "score" used to look like this: [form-property name="score"
initial="100"/] -->
<form-property name="attempts" type="java.lang.String"/>
</form-bean>
subForm will end up with:
<form-bean name="subForm"
type="o.a.s.a.DynaActionForm">
<form-property name="firstName" type="java.lang.String"/>
<form-property name="lastName" type="java.lang.String"/>
<form-property name="score" type="java.lang.String" initial="100"/>
<form-property name="attempts" type="java.lang.String"/>
</form-bean>
"subForm" can no longer just provide the minimum required when
overriding/extending properties. It either specifies the form
property fully, or accepts what the base config provides it. This
would make it consistent with how <action>s deal with <forward>s and
<exception>s.
Comments appreciated.
Hubert
On Tue, 29 Mar 2005 21:16:20 -0600, Hubert Rabago <hr...@gmail.com> 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