RichMarker Utility Library

[Luke Mahé]

Hey everyone!

I've checked in another utility library that I've written, it's called RichMarker and it is pretty much what happens when a Marker meets a InfoWindow :)

You can put any sort of html in it, like you would a InfoWindow and you can position and drag it like a Marker.

If you're interested, you can read the reference doc:

http://google-maps-utility-library-v3.googlecode.com/svn/trunk/richmarker/docs/reference.html

And play with the example:

http://google-maps-utility-library-v3.googlecode.com/svn/trunk/richmarker/examples/richmarker.html

Let me know if you run into any problems/bugs. I haven't really tested it on IE so feel free to help me out :)

- Luke

[William]

On Aug 13, 1:41 pm, Luke Mahé <lu...@google.com> wrote:
> I haven't really tested it on
> IE so feel free to help me out :)
>

great library thanks Luke!

I gave it a go on IE8 and got an error because preventDefault() isn't
supported on IE DOM events, so you'll have to test whether it exists
before calling it:

if (that.getDraggable()) {
e.preventDefault(); // Error: Object doesn't support this
property or method
e.returnValue = false;
}

...

[Luke Mahé]

Thanks for that, I've added a check for preventDefault.

-- Luke

--
You received this message because you are subscribed to the Google Groups "Google Maps JavaScript API v3" group.
To post to this group, send email to google-map...@googlegroups.com.
To unsubscribe from this group, send email to google-maps-js-a...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-maps-js-api-v3?hl=en.

[William]

It still didn't drag for me in IE8, and it seems because the events
are being captured by the marker elements, not the window.

I could make it drag by changing the following from "window" to
"this.markerContent_" but it doesn't really work on images because it
starts to drag then something stops it and the cursor goes off the
image, so you have to move the cursor back over the Eiffel tower image
to continue dragging:

ORIGINAL
RichMarker.prototype.addDraggingListeners_ = function() {
var that = this;
this.draggingListeners_ = [
google.maps.event.addDomListener(window, 'mousemove', function(e)
{
that.drag(e);
}, true),
google.maps.event.addDomListener(window, 'mouseup', function() {
that.stopDrag();
}, true)
];
};

CHANGED
RichMarker.prototype.addDraggingListeners_ = function() {
var that = this;
this.draggingListeners_ = [
google.maps.event.addDomListener(this.markerContent_, 'mousemove',
function(e) {
that.drag(e);
}, true),
google.maps.event.addDomListener(this.markerContent_, 'mouseup',
function() {
that.stopDrag();
}, true)
];
};


...

[Luke Mahé]

I think I've got it working now, have another play :)

-- Luke

--

[William]

yeah drags good now, but I noticed after you drag the bottom of the
Eiffel tower image south of the equator, when you zoom in the Eiffel
tower moves south, and when you zoom out it moves north (on IE8, FF3.6
and Chrome)

...

[Luke Mahé]

Thats because the anchor of that marker is bottom middle :) You can put the anchor anywhere you want but by default it works like a marker and goes to the bottom middle of the object.

Hope that makes sense.

-- Luke

--

[William]

On Aug 13, 3:47 pm, Luke Mahé <lu...@google.com> wrote:
> Thats because the anchor of that marker is bottom middle :)

oh I see that makes sense now!

...

[Nianwei Liu]

Luke,
Very nice! I looked through your code and had a few observations/
comments:

-- In compiled version, no 'output_wrapper' was added as compile
parameter, the resulted script started with a global function b().
There is a good chance of clashing with other code compiled without
the anonymous function wrapper.
-- In the similar context as above, is it time to have a namespace?
Conversation started long time ago but never nailed down.
-- are you using the jsdoc util in the project? I did not see any
@event annotation in the code and as far as I recall the doc util
won't produce event doc without it. If you are using a different jsdoc
tool, can that be shared in the util lib? There are some issues with
closure style type def syntax for the current tool.
-- I've been back and forth on coding styles trying to accommodate
needs of both exporting as a lib and at same time allow lib compiled
with app code together to take advantage of dead code removal. (That
may allow more code sharing between lib utils and potentially use the
util lib same way as closure lib, i.e. app code use pieces as needed
without include individual scripts, but that's a different
discussion). One issue is that the enumeration values such as your
RichMarkerPositions. The use code would have to use quote syntax
instead of the dot syntax which is more intuitive. I opted to move the
enums to an extern and use it when compiled as a lib but not use it
when compiled with app (that will cause the enums got renamed too
which is a good thing). Wondering what's your thoughts on that.

[Luke Mahé]

On Sun, Aug 15, 2010 at 10:18 PM, Nianwei Liu <nia...@gmail.com> wrote:

Luke,
Very nice! I looked through your code and had a few observations/
comments:

-- In compiled version, no 'output_wrapper' was added as compile
parameter, the resulted script started with a global function b().
There is a good chance of clashing with other code compiled without
the anonymous function wrapper.

I've added a output wrapper, thanks for picking that up.

-- In the similar context as above, is it time to have a namespace?
Conversation started long time ago but never nailed down.

 

Sure, but we never came up with a good name :) The API team does not want to have the utility libraries use the google.* namespace because it can cause confusion as to what is a official library and what is not. I am totally open to using a namespace once we have decided on what, feel free to offer suggestions :)

 

-- are you using the jsdoc util in the project? I did not see any
@event annotation in the code and as far as I recall the doc util
won't produce event doc without it. If you are using a different jsdoc
tool, can that be shared in the util lib? There are some issues with
closure style type def syntax for the current tool.
-- I've been back and forth on coding styles trying to accommodate
needs of both exporting as a lib and at same time allow lib compiled
with app code together to take advantage of dead code removal. (That
may allow more code sharing between lib utils and potentially use the
util lib same way as closure lib, i.e. app code use pieces as needed
without include individual scripts, but that's a different
discussion). One issue is that the enumeration values such as your
RichMarkerPositions. The use code would have to use quote syntax
instead of the dot syntax which is more intuitive. I opted to move the
enums to an extern and use it when compiled as a lib but not use it
when compiled with app (that will cause the enums got renamed too
which is a good thing). Wondering what's your thoughts on that.

I did the RichMarkerPosition thing for improved readability of the code but I am tempted to ditch it and just allow strings to be passed in instead, what do you think?

[Nianwei Liu]

> Sure, but we never came up with a good name :) The API team does not want to
> have the utility libraries use the google.* namespace because it can cause
> confusion as to what is a official library and what is not. I am totally
> open to using a namespace once we have decided on what, feel free to offer
> suggestions :)

I've been using "gmaps" cause it's simple and short. For bigger libs
may have a sub namespace but the smaller ones just under it directly.

> I did the RichMarkerPosition thing for improved readability of the code but
> I am tempted to ditch it and just allow strings to be passed in instead,
> what do you think?

I do not have preference one way or the other. Using enum may have a
remote benefit of having some IDE prompt a list, also reduce chance of
typo, but not that big of a difference.

What about the jsdoc util? I ran with the jsdoc tool in the project
and it hit error and nothing get generated. Is there barriers to
release your internal jsdoc tool to this project? I figure it's same
tool just different template.

[magicrat75]

Hi Luke

I really like the library and just started using it for a new development.

However, I've found a werid problem in the new Firefox versions (6.x), as it doesn't gets an onclick event!

I've written a new message in the forums for this error:
https://groups.google.com/forum/?fromgroups#!topic/google-maps-js-api-v3/8H6K_G5s4zU

Hope you or anyone can tell me how to fix this.

Thanks.
D.