I guess most people are waiting for Google to release it. Although it
would be good if Google could let us know when they plan on releasing
it because we could reverse engineer it if it's a long way off.
Michael
On 10/11/05, Maxwolf <Ron.McDow...@gmail.com> wrote:
>The API we mess with and the API they mess with are two difftrent
>things.
The Javascript used by Google Local is identical to that used by the
API. The only difference is that we access the functions by calling them
from our code, and Google Local throws an XML file at loadXML().
There are bits of code inside loadXML() that don't have exact
equivalents in the callable functions.
In the case of tabbed windows. The code seems to be all there. It looks
like "all" you have to do is to use .openInfoWindow() with a correctly
structured HTML DOM element. (.openInfoWindowHtml() isn't going to work
because the DOM element it constructs to pass to .openInfoWindow() isn't
structured for tabs).
My current thoughts are that infoWindow.collectTabElements() is probably
the key. It's responsible for examining the infowindow DOM and
determining how many tabs the infowindow should have.
Under normal circumstances, collectTabElements() makes b.length = 1,
then the following code happens, and we end up with hidden tabs.
I don't know how to look at the HTML DOM elements passed from the Google
Local XML into loadXML() so observe their structure, and I've not yet
managed to reverse engineer collectTabElements() to see what it wants.
I'm still working on it.
>I don't know how to look at the HTML DOM elements passed from the Google
>Local XML into loadXML() so observe their structure, and I've not yet
>managed to reverse engineer collectTabElements() to see what it wants.
>I'm still working on it.
I've now got a little bit further. It turns out that it is possible to
make collectTabElements() return a value greater than 1 by having more
than one top-level elements in the html string which all contain a
"page" attribute.
marker.openInfoWindow('<div page="this">Contents of first page</div>
<div page="that">Contents of second page</div>');
Which gets me as far as the infowindow.showTabs() function.
The next problem is that showTabs() needs more information about the
info window, mainly for the setting up of the GEvent.callback function
that's going to handle what happens when the user clicks on one of the
tabs.
It performs this check:
var b=this.infoWindowContract;
if(!b.hasContext("iwnavigate")||!b.hasContext("iwstate")){
return
}
Under normal circumstances the infoWindowContract doesn't have either of
those contexts, so the tabs don't get shown.
In the Google Local environment, the "iwstate" context is set up as:
a.addContext("iwstate",j.callback(this,this.iwState));
The callback is just a method that acts as a sort of dumb "GEvent.bind": GEvent.callback=function(caller,object) { var callbackFunction = function() { return object.apply(caller,arguments)
}
So, any object that you pass to GEvent.callback must have an apply method: $.prototype.apply=function(a){a.style.position="absolute";a.style[this.getW idthMeasure()]=l(this.offsetWidth);a.style[this.getHeightMeasure()]=l(this. offsetHeight)}
$ looks to be the generalized styling class, and not much more.
When you create a context, you have to pass in a function that gets called on each context (from _traverse) each time something changes. My guess is that they do this to make sure the sizing and positioning is guaranteed to be correct.
Quick analysis, I'm sure I'm wrong on a few points but I hope this helps you guys.
I could be wrong, I still believe all the pieces you need will not be there but you guys seem to be in the middle making it happen right now. Personally I would think they (Google) would tell us about this and document it with the rest of the API.
