Using Extends with validate or unknown

[Ted Husted <te...@gmail.com>]

Given

        <action path="/Register"
                name="RegisterForm"
                validate="false"
                ...
                />

        <action path="/RegisterSave"
                extends="/Register"
                validate="true"
                .../>

The value of validate remains false.

The controlling code is at ActionConfig, line 1089

* http://tinyurl.com/a88jm

        if (getValidate()) {
            setValidate(config.getValidate());
        }

which for this use case resolves to

       if (true) {setValidate(false)}

We probably have the same problem with "unknown", which is tjhe other boolean.

Evidentally, the test wants to be sure that extends does not step on
any values already set. Except for the two booleans, we otherwise test
for null, and this strategy seems sound, since we don't have a
mechanism for setting a null from a configuration file.

I've only started to think about this, but wanted to fire something
off in case someone saw an obvious solution.

-Ted.

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

Re: Using Extends with validate or unknown

[Hubert Rabago <hr...@gmail.com>]

(Apologies for the late reply; I've been offline.)

On 1/3/06, Ted Husted <te...@gmail.com> wrote:
> Given
>
>         <action path="/Register"
>                 name="RegisterForm"
>                 validate="false"
>                 ...
>                 />
>
>         <action path="/RegisterSave"
>                 extends="/Register"
>                 validate="true"
>                 .../>
>
> The value of validate remains false.
>
<snip/>
> We probably have the same problem with "unknown", which is tjhe other boolean.
>
> Evidentally, the test wants to be sure that extends does not step on
> any values already set.

Correct.

> Except for the two booleans, we otherwise test
> for null, and this strategy seems sound, since we don't have a
> mechanism for setting a null from a configuration file.
>

We also have boolean props in other config classes.
The problem is not only with booleans, but with ints as well (like
FormPropertyConfig's "size").  If there are String props which need to
distinguish between null and an empty String, the problem is there as
well.

Right now, this is a limitation of the "extends" functionality. 
("Can't reset a field to a default value once a base config sets it")

> I've only started to think about this, but wanted to fire something
> off in case someone saw an obvious solution.

If we solve this for booleans and ints, shouldn't String fields be
allowed to go back to default values as well?

> -Ted.
>

Hubert

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