Validating one component from another one

I have two date fields, which I use in a start/end -context. I want to restrict that the “start” DateField needs to be later than the “end” DateField. I’ve got the validator set in the “start”-field, and it works fine, if you select first a “start” date, and then enter an erroneous “end”-field.

But, if I first enter valid values to both fields, and then afterwards, in “start”, I put a later date than what “end” is. I then want the “end”-field to become invalid.

Is it possible to trigger a validation check into the “end” field from the “start” field, so that “end” gets invalidated, and not “start”?

My code is currently as follows:

start = new DateField("start:");
end = new DateField("end:");


end.addValidator(new Validator() {
    public boolean isValid(Object value) {
        Date date = (Date) value;

        if (start.getValue() == null) {
            return true;
        } else {
            return (date.after((Date) start.getValue()));
    public void validate(Object value) throws InvalidValueException {
        if (!isValid(value))
            throw new InvalidValueException("beep");

start.addListener(new ValueChangeListener() {
    public void valueChange(ValueChangeEvent event) {

Could the ValueChangeListener be common for both, where both field’s .validate() is run?

Furthermore, wouldn’t it be nice if the field’s date would be moved into the valid range, if the current date would be invalid? Say you have 10.2008 - 2.2009. If you move start to 5.2009, end would automatically move to a later date like 6.2009?

This ‘pattern’ is quite nice: Moving start forward moves end forward the same amount, end can’t be moved before start.
It sort of depends on your situation (how the users usually perceive the date range and proceeds to enter the values), but usually this is a very usable ‘pattern’ (well, ‘ruleset’, pehaps, but ‘pattern’ sounds so much more standardized :wink:
This very seldom requires the user to enter more data than the ‘dumb’ version, and quite often does exactly what the user wanted.

Initial start 1.1 end 3.1, user moves start to 2.1, end automatically moves to 4.1.

Best Regards,

Hm. This might be a good compromise, although I’d rather have the user react to invalid input than have the system guess what the user might want/intend/need.

Anyhow, thanks for the workaround, I’ll use this.