StatefulCanvas mouseOver/mouseOut

[ect]

When adding a mouseOver/mouseOut handler to a StatefulCanvas via SmartGWT 3.1, the code in Canvas.java (setupMouseOverEvent, setupMouseOutEvent) effectively replaces the standard implementation of mouseOver/mouseOut in StatefulCanvas.js.
As far as I can see, there is no possibility to trigger the standard behavior (rollover effects) from within the GWT event handler anymore.
This seems to me like a rather unique and surprising implementation choice here. Normally, SmartGWT event handlers act nicely together with the SmartClient implementations, for example, drag and drop events: I can add my custom implementation and still decide whether the standard behavior should be executed or not (by invoking cancel() on the event).
I find it somewhat odd and inconsistent that I must reimplement the standard behavior manually for mouseOver/mouseOut when adding the corresponding SmartGWT handlers.

[Isomorphic]

Hi ect
Thanks for the report. We agree that this sounds like unexpected behavior. One of our developers will be taking a look at this issue and we'll let you know what we find.

Regards
Isomorphic Software

[Isomorphic]

We're going to make a change to address this limitation.
We're planning to make this change to the development codebase (the 9.0d SmartClient / 4.0d SmartGWT branch) - patching back to 3.1p may be possible but it will involve a low level change which we don't want to patch across unless this is actually blocking development.

Regards
Isomorphic Software

[ect]

Actually, this is a rather tricky one, I guess. This kind of pattern is possibly used more often throughout the framework.

I would propose to do a full text search for classes that define event methods that are candidates to get overwritten when adding GWT event handlers.

Another example: Layout::dragRepositionStart

Same as the original issue with mouseOver/Out on StatefulCanvas: the default behavior gets lost when adding a DragRepositionStartHandler on the Layout.

I think the best approach in general would be to preserve these default implementations when adding an event handler via GWT, but allow the programmer to bypass the default behavior.

Note that event.cancel() does not work in all cases:

Let's assume we can add the GWT handler non-intrusively in future. This might create another type of issue, in case the programmer wants to cancel the default behavior. Calling event.cancel() might have other side-effects, like cancelling the whole DND interaction instead of a single default behavior.

In detail: Assume we have a canvas C as a member in layout L. We want to perform custom drag handling with C, so we register a DragRepositionStartHandler on C. The DragRepositionStartEvent will get bubbled up to L. L defines default behavior on behalf of C: C gets deparented from L by the default implementation. This might be an unwanted behavior in the context of our custom implementation. How to cancel this? Calling event.cancel() would cancel the whole drag interaction.
Maybe, in future we need an additional API call, sort of event.cancelDefaultBehavior() which controls from within a handler whether default behavior should be executed or not without influencing the event chain.

[Isomorphic]

We've now made a change to the 4.0d branch which should ensure that the default rollOver stateful styling continues to occur if you have a custom mouseOver (etc) handler in place - and that cancelling the event suppresses this styling.

With respect to your more general question - yes there may be other cases where implementing an event handler overrides the default behavior and we can look at these case by case if you experience problems with them.
The desired behavior will vary by component and by use case.

Your specific point about attempting to cancel part of a behavior (suppress the default implementation but not kill the event) is also something which we really have to answer case by case. We probably would not have exactly the pattern you describe - "cancelDefaultBehavior()" - instead we usually provide framework level flags to disable the default behavior entirely (such as the Layout.canDropComponents attribute) without necessarily cancelling the entire event flow (as would happen if you returned false from the event).

The bottom line on this is - if you hit other cases where you can't get your desired behavior, please let us know exactly what you're trying to do and in what way the framework is not facilitating this, and we'll either comment on recommended approaches, or look into whether we need to add some capabilities to the framework.

Regards
Isomorphic Software