Editable date fields

[yavery]

Hi,

I'm migrating from 8.2p LGPL to 8.3p Pro (01/22/2013) and I ran into the following issue ...

Whenever I edit a date (and set a value) using the date picker, its modal mask
doesn't go away when the date picker popup is dismissed, therefore I can't
click anywhere else.

If I click cancel without choosing a date in the date picker, the modal mask goes away,
as expected.

The above behaviour can be observed both from IE and Chrome.

Any idea ? Is this a new bug in 8.3p ?

PS: Also noticed a styling issue with those days outside the month being looked at ...

Thanks,

[Isomorphic]

This hasn't been reported before and is probably some kind of interaction between new DateChooser features and customizations in your application like custom time or date formatters and parsers.

Also, it seems like the only way this could happen is if there was a JS error. Are you seeing one?

[yavery]

No scripting error when this occurs, but we do have custom date formatters and such. I'll further investigate and keep you updated.

Thanks,

[yavery]

Found the culprit but don't understand ...

Hi,

I found the culprit code (which worked in 8.2p LGPL and broke with 8.3p Pro).

When I step into the code, it goes where it's expected to ...

I don't understand:

1) why the mask gets stuck because of this custom logic
2) is there another approach to how we've done this custom behaviour
injection? Following is the code ...

// grab copy of the original showPicker() method so we can call it from our spoofed version
isc.DateItem.addMethods({ showPickerOriginal : isc.DateItem.getPrototype().showPicker });

// attach new showPicker() method to have custom logic injected
isc.DateItem.addProperties
({
	//----------------------------------------------------------------------------------------------------------------------------
    showPicker : function ()
	{
		if (this.isReadOnly())
			return false;

		if (this.showPickerOriginal)
			return this.showPickerOriginal(arguments);

		return true;
	}
});

Thanks for any suggestions,

[Isomorphic]

It looks like the problem is a subtle one to do with the renaming of the "showPicker" function confusing internal code within that method.

You could probably solve this by creating a subclass of DateItem with your modifications. Something like this:

isc.defineClass("CustomDateItem", "DateItem");
isc.CustomDateItem.addProperties({
    showPicker:function () {
        if (someCondition) return false;
        return this.Super("showPicker", arguments);
    }
});

In order to make use of this new class you would have to specify editorType on the field in question (can be done at the DataSource or the component level).
Or to change this for all date type fields, you could set the get the SimpleType definition for "date" and apply your new className as the editorType for that simpleType object.

Regards
Isomorphic Software

[yavery]

Yes. I know about the subclass approach, but as you outlined, this would require
us going everywhere and adding the "editorType" property to all date fields in all
data sources.

This is why we chose the "spoofing" approach which SHOULD work. I still don't
understand why it doesn't ... Any more precision on that would be appreciated ...

Wouldn't there be a more central way, other than spoofing (if that doesn't work, for
whatever reason?), such as a factory method that gets called when a date field is
encountered by the framework, so that I could replace the creation of a DateItem by
the creation of my subclassed CustomDateItem instance instead?

Thanks,

[Isomorphic]

Your function renaming broke our implementation of Super() because of issues figuring out which is the next superclass in the call chain, which relies on function identity.

Writing an efficient implementation of Super() that handles all the edge cases (ordinary recursion, inter-recursion between two chains of Super calls, etc) is extremely complicated, and relies on function identity. We basically have no reasonable way of writing Super() that would handle this case and be reasonably efficient.

So this is a place where we have to recommend the supported approach of using subclasses.

[yavery]

Thanks for that clarification which totally makes senses. Now, is there a factory method that I
could override to have my custom DateItem derived class created instead of the default one?

That approach would simplify the process a whole lot ...

Thanks,

[Isomorphic]

You could override dynamicForm.getEditorType().

[yavery]

Will try that approach. Thanks!