disabling DateItem's implicit isDate validator

[twelve17]

Using SmartGWT 2.4...

I read on another post that DateItem contains an implicit isDate validator. I can verify this by creating a DynamicForm with a DateItem (which itself has a textItem field), entering a bogus string (like "foo"), then calling validate on the DynamicForm. A validation message is shown on the DateItem: "Must be a date.".

If I call setValidators() on the DateItem and provide my own validators, the implicit isDate validator seems to be getting called after my own validators.

If a non-valid date value is entered, the resulting Object passed in to validators is a String type.

In some cases, this is fine. For example, if the DateItem just has a single RequiredValidator, as it doesn't care about the value type as much as it cares that the value is not null.

However, if I want to do other validation where I do want to care that the Object passed in is a date, then having the implicit isDate validator last doesn't make much sense, as I would want to validate that first, then optionally validate the other bits.

Is there a way to disable this implicit validation, and maybe expose it as a Validator sub-class, so that one can optionally control when to run it within the array of validators?

[Isomorphic]

The design is that the implicit validators run first unless you re-declare the implicit validator explicitly, in which case it runs in the order you've defined. Please show a test case if you think it's not behaving this way.

[twelve17]

The design is that the implicit validators run first unless you re-declare the implicit validator explicitly, in which case it runs in the order you've defined. Please show a test case if you think it's not behaving this way.

Sounds good. I will create a test case to see how it behaves. How do I explicitly declare the isDate validator? I found it in the javascript sources, but did not see a equivalent Java class for it.

[twelve17]

I was still unable to find a Java validator for the isDate JS validator. I looked at the SmartClient source and attempted to come up with what such a thing would be:

    public static class IsDateValidator extends Validator {

        public IsDateValidator() {
            setAttribute("type", "isDate");
        }

        /**
         * Set the value.
         * 
         * @param value the value
         */
        public void setValue(Date value) {
            setAttribute("value", value);
        }

        /**
         * Return the value.
         * 
         * @return the value
         */
        public Date getValue() {
            return getAttributeAsDate("value");
        }
    }

I'm not convinced I did this right. My test app is not showing usage of this validator "canceling" the implied isDate validator, and I suspect it is because of the way I wrote this class.

[Isomorphic]

There is no need to be able to specify an isDate validator in order to create a reproducible case of the behavior you describe.

[twelve17]

Maybe I misunderstood the earlier quote?

The design is that the implicit validators run first unless you re-declare the implicit validator explicitly

The implicit validator is the isDate validator. How do I explicitly re-declare the isDate validator in SmartGWT?

[Isomorphic]

From what you said before, the problem you're having is that the isDate validator runs last. But the design is that it runs first. Therefore you shouldn't need to explicitly declare it at all, and if there's a problem, you should be able to create a test case showing it. Clear now?

[twelve17]

From what you said before, the problem you're having is that the isDate validator runs last. But the design is that it runs first. Therefore you shouldn't need to explicitly declare it at all, and if there's a problem, you should be able to create a test case showing it. Clear now?

Ah. Let me clarify: I am writing the test case, but was having trouble determining when the implicit isDate validator is running, as there does not seem to be an equivalent Java class I could put a breakpoint in, and I did not have luck configuring the SC client side console logging to show the validators as they fire, thus I could not determine the order in which they are firing.

Thus, I changed direction to see if I could just re-declare the validator as you mentioned, as that would provide more control over the validation of a field, and could not figure out how.

If you have suggestions on how I can verify the order of the implicit validator along with explicit validators, I will be glad to update my test case code.

[Isomorphic]

It has a simple side-effect: if the value being validated is a String, it is changed to a Date for subsequent validators (assuming it's a valid Date).

[twelve17]

It has a simple side-effect: if the value being validated is a String, it is changed to a Date for subsequent validators (assuming it's a valid Date).

I guess the implication here is also that if the implicit isDate validator fails, it does not stop subsequent validators?

[Isomorphic]

That depends on validator/formItem/field.stopOnError.

[twelve17]

That depends on validator/formItem/field.stopOnError.

Since the implied isDate validator is created on one's behalf, what is its stopOnError value? And its stopIfFalse value?

[twelve17]

I have done some further testing and found a hint towards the underlying issue that was prompting me to want to disable the implicit isDate validator.

It appears that if you call setValidator() on a DateItem after the dynamic form has been added to a window, the implicit isDate validator is not added to the DateItem.

To verify this, I created a test widget class that extends Window, which creates a form inside the window. The form creates a DateItem instance, and calls setValidator() with a single validator: isBooleanValidator. Since we are dealing with dates, this validator should conflict with the implicit in isDate validator.

The class also takes a boolean that causes it to either set the validator after or before addItem(form).

When the custom validator is added before, the validation works as expected: both isDate (implicit) and IsBoolean(explicit) are executed.

When the custom validator is added after, only the explicit validator is executed.

The test class is attached as FormWindow.java.

I called this class from my GWT entry point like this:

       mainCanvas = new Canvas();
        mainCanvas.setWidth100();

        Window window1 = new FormWindow(false);
        window1.setPosition(Positioning.ABSOLUTE);
        window1.setLeft(10);
        window1.setTop(200);
        mainCanvas.addChild(window1);

        Window window2 = new FormWindow(true);
        window2.setPosition(Positioning.ABSOLUTE);
        window2.setLeft(10);
        window2.setTop(10);
        mainCanvas.addChild(window2);

        mainCanvas.draw();

[Isomorphic]

Yes, as a general pattern, don't try to modify fields (on a ListGrid, DynamicForm or otherwise) after the grid/form etc has drawn. If you need something like this, call setFields()/setItems() with the complete set of new fields/items instead. We've been adding mentions of this to the docs in various places to prevent this problem.

[twelve17]

Thanks for the heads up. Going back to the isDate implicit validator--how do I explicitly declare it? I didn't have much luck finding that in the javadoc. Thanks again.