gwt jsni callbacks implementation about gwt-maps-v3-api HOT 23 CLOSED

google docs about $entry()

https://developers.google.com/web-toolkit/doc/latest/DevGuideCodingBasicsJSNI#calling

from gwt-maps-v3-api.

I have no reason not to have it that I can think of. Good find.

from gwt-maps-v3-api.

I wonder if that would fix our _gwt_object issue that shows up. :)

from gwt-maps-v3-api.

I haven't encountered that, yet. Are you talking about #11 ?

from gwt-maps-v3-api.

Interesting. I recall seeing it when I read the JSNI API doc's, but they said it:

1. ensures that the Java-derived method is executed with the uncaught exception handler installed
2. pumps a number of other utility services
3. is reentrant-safe
4. should be used anywhere that GWT-derived JavaScript may be called into from a non-GWT context

The final point suggests it should be there, so shame on me. However, points 1/3 don't seem pertinent. Perhaps "service pumping" does something special, but I've never heard of it.

Nevertheless, certainly worth implementing in the API.

from gwt-maps-v3-api.

Hi Joseph, nice to find you in another free software project ! ;)

I will tell you that in mine two major GWT libraries based on jsni and overlay types (JavaScriptObject), this is http://code.google.com/p/raphael4gwt/ and http://code.google.com/p/yuigwt I use $entry() in EVERY jsni code that calls java code from javascript. But I have seen that this is not mandatory and in most cases it only impact the application when running it on the devel mode. I don't think it has impact on compiled code running in production.

IMHO working with $entry() you have a more refined way of controlling exceptions that happens on the javascript side. For example think on two or more java native (jsni) methods that call each other and call 3rd party javascript code. If at some point a javascript exception occurs, if we are using $entry() the develmode will will handle the exception in a more java friendly way and it is more easy to realize the cause of the exception when developing.

Also, recently I found a case where using $entry() actually break my code, but this was in a very special case. This was when trying to port the YUI tests utilities. There, a native javascript-YUI class helper for testing, contains methods assertTrue(), assertEquals(), etc (like junit) and internally the javascript code was using javascript assertations directly. Internally if the assert failed it throws a javascript exception and that is how the framework count failed asserts internally (catching exceptions) . But because I was using $entry(), the jsni method call never throwed the javascript exception out of the method and so the testing framework didn't worked in java. Also an exception stacktrace was displayed on the develmode console when internally a javascript assert fail. This problem was fixed simply by removing $entry().

So in my opinion $entry() is good for develmode because it will help you visualize the cause of exceptions throwed from native js code, but be carefull because it will catch those exceptions and this could break the desired behaviour in those special cases. But in general your java users will thank you.

my 2 cents.

from gwt-maps-v3-api.

Thats good info, thanks for sharing :)

from gwt-maps-v3-api.

I will stay in touch and show you an application that uses google maps (with this nice lib of yours) with a YUI (yahoo) user interface... Nice work the two of you !

from gwt-maps-v3-api.

Nice. I'll look forward to seeing your app. :)

from gwt-maps-v3-api.

final thought: this lib is working nice, at least for me. IF it work ok, adding $entry() in al jsni calls can be a pain.... But if some strange bug / behavior is seen, perhaps not using $entry() can be the cause of it and should be taken in consideration.

from gwt-maps-v3-api.

Great idea. I'd like to aim to add that. I want to see how it deals with the __gwt_Object property.

from gwt-maps-v3-api.

Brandon,

I see that you placed a lot of $entry() calls in the code recently. Can you do a code search and make sure all the bases are covered with these before we do v3.9 release? Thanks.

from gwt-maps-v3-api.

I can, but I won't be able to make time till about thursday to saturday. I'm aiming to work on it off work time. :)

from gwt-maps-v3-api.

this is a response from Thomas Broyer from GWT groups about using $entry(). Besides exceptions there has also something to do with Scheduler:

You should wrap your function in $entry() so that a) exceptions are routed to the GWT.UncaughtExceptionHandler and b) Scheduler.scheduleEntry and Scheduler.scheduleFinally run appropriately. Also, note that you could pass the event to your Java code as a NativeEvent:

e.onclick = $entry(function(e) {
handler.@org.sgx.gwtraphaljstest.client.js.test.DomEventTest1.ClickHandler::notifyClick(Lcom/google/gwt/dom/client/NativeEvent;)(e);
}

Original thread

from gwt-maps-v3-api.

Is there a reason why you would want to pass to native event instead of bubbling the event up the widgets?

from gwt-maps-v3-api.

I think passing to native event would make things messy for the lib, but thats my thought. I do like adding entry to the re-entry of the javascript jsni to java methods.

from gwt-maps-v3-api.

in my case, I am not working with GWT widgets. In my both libraries, http://code.google.com/p/raphael4gwt/ and code.google.com/p/yuigwt I'm working 100% using JavaScriptObject (overlay types) and both are fully independent on GWT widgets. They are based on GWT dom.client package (Element, NativeEvent, etc). These GWT dom.client overlay types will do the work of normalizing stuff.

Nevertheless I wanted to share the feedback I get from one of the GWT developers about using $entry(). Regards

from gwt-maps-v3-api.

Thanks for the input. :)

from gwt-maps-v3-api.

Cool library and nice demos! Interesting, I've been re-working an gwt svg lib revamping so it would use gwt widgets. https://github.com/EngOnyx/lib-gwt-svg and my dnd sandbox http://svgsandbox.appspot.com/ :)

from gwt-maps-v3-api.

the same to your libraries ! raphaël main feature is that its API support browsers with no SVG, like IE<9. In those browsers it is implemented over VML (a MS vector drawing standar). So the API must work in both implementations SVG and VML. This feature has good and bad consequences. The bad consequence is that raphaël won't include any SVG feature that cannot be implemented in VML so it is kind of reestricted. In mine raphael4gwt I added out of the box SVG-only features, like filters : http://cancerbero.vacau.com/gwt/raphael4gwtGallery/?test=SvgFiltersTes

from gwt-maps-v3-api.

Thats cool. I have to admit the svg library that I worked on was already being used for someones project and caused a real mess with memory which I fixed but I'm not pleased with it's architecture. But I can see yours has a nice source quality to it :)

from gwt-maps-v3-api.

I used lib-gwt-svg to make some impressive UI's last spring. It worked well, but only on Win Vista/7 due to Mozilla Cario SVG bugs and a BeginEvent bug in WebKit. Would have been nice to do it in Raphael to cover more browsers/quirks.

from gwt-maps-v3-api.

#120 - added $entry

from gwt-maps-v3-api.