Hi Alberto, Thanks for hanging in there. I hope you enjoyed Developer Day.
On Fri, Sep 26, 2008 at 8:01 AM, Alberto Núñez <[EMAIL PROTECTED]> wrote: > > Well, now that the RC of gwt-maps with the new API is out, it's time > for me to ask again (http://groups.google.com/group/Google-Web-Toolkit/ > browse_thread/thread/c2c12a9b5b297f7a/fa8d113d1e00a4b5<http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/c2c12a9b5b297f7a/fa8d113d1e00a4b5>) > for an issue I > have been struggling with for some time. Yesterday I had the > opportunity to ask Sumit Chandel about that in Madrid's GDD, and it > seems it's a kind of tricky problem. > Sorry, when I read and responded to your post, I didn't realize the full extent of the issues you outline below. > I am trying to use the LabeledMarker library (JavaScript, not GWT) > with gwt-maps. That library provides a subclass of Marker, > LabeledMarker, and a subclass of MarkerOptions, LabeledMarkerOptions. > In order to use the library, the first approach I took was to modify > the gwt-maps source code so that the Marker class is always > instantiated as a LabeledMarker object (http://groups.google.com/group/ > Google-Web-Toolkit/browse_thread/thread/ > 9f618c768dd6d126/1edaaf5c91f9aa9d<http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/9f618c768dd6d126/1edaaf5c91f9aa9d>). > The obvious disadvantage of this > is that I have to patch the code everytime the gwt-maps library gets a > new update. > > These are the guilties that take a role in this "programming soap > opera": > > - The MarkerImpl interface, that extends JSFlyweightWrapper. It's the > wrapper of the original GMarker, that uses JSIO. I think you can bypass this: see below. > - The Marker class, which extends ConcreteOverlay. Uses MarkerImpl in > its constructor to create the JavaScript object. I think you can bypass this too. > > - The MarkerOptions class, extends JavaScriptObject, declared final > and written using JSNI. Passed as an argument to the Marker > constructor. I mistakenly made the entire class final instead of just the methods. > > > Therefore: > > - MarkerOptions cannot be subclassed because its final. This was a mistake I will rectify in a moment. > > - A subclass of Marker would need a subclass of MarkerImpl that > pointed to the LabeledMarker JavaScript class. But that cannot be made > as the constructor of the Marker subclass is forced to call the Marker > constructor, that uses MarkerImpl. Is then any way to make the Marker > subclass call use a MarkerImpl subclass in its constructor? I don't think your LabeledMarker() subclass needs to call the constructor that calls MarkerImpl. For example, make a new constructor that overrides the Marker(LatLng) version: public LabeledMarker (LatLng point) { super(LabeledMarkerImpl.construct(point)); } this ends up calling ConcreteOverlay(JavaScriptObject) You would only need to define the methods in LabeledMarkerImpl that are new to this subclass. Another way to make this work is to make your custom LabeledMarker a subclass of Overlay in this case, not Marker. You would have to duplicate the methods inside of Marker ort you could provide a getMarker() method. Marker marker; public Marker getMarker() { if (marker == null) { marker = Marker.createPeer(jsoPeer); // note, this method is currently package protected! } return marker; } -- Please let me know if either of those approaches works for you. -- Eric Z. Ayers - GWT Team - Atlanta, GA USA http://code.google.com/webtoolkit/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
