[OpenLayers-Dev] Tile.checkImgURL, path processing
Christopher Schmidt
crschmidt at metacarta.com
Thu Jan 18 11:36:38 EST 2007
Currently, OpenLayers has a function in the Tile, called checkImgURL,
which checks that a Tile has the same source after it was loaded as we
expect it to, and otherwise hides the tile.
This function was partly debugging and partly important: for a time,
tiles were loading where they shouldn't have been, and it was causing
problems.
However, I think that this behavior is now fixed: a tile never loads and
has a different source than the one we asked it for. (As proof of this,
you can try turning this function off: I do it in all of the places that
I set up OpenLayers, pretty much.) The code to do this is:
OpenLayers.Tile.Image.prototype = OpenLayers.Class.inherit(
OpenLayers.Tile.Image, { checkImgURL: function() {} });
A side effect of this check, because of the way that browsers process
URLs, is that it breaks relative URLs in Firefox. Fixing this so that it
works well is a difficult problem -- essentially, it takes the same
difficulty as writing a full URL path parser. (Python's urlparse module
is an example of code which does this, and it's non-trivial.)
At this point, I think that we've solved the problem this function was
trying to prevent in other ways, via improvements to the Grid.js code,
etc.
I'm in favor of removing this check. The benefits:
* No URL path parsing, so relative URLs will work again in FF, for
example.
* No need to implement a complex functionality for checking URLs
which is seldom used.
Cons:
* Possibly no longer hiding possible errors where somehow the tile.src
changes during the load, but the tile doesn't load the correct URL.
There is another option of making this check optional, turned off by
default, and settable as an option on a layer. That way, we could keep
the current behavior for people who want it, but since it has caused
more harm than good, default it to off. This would be useful if we find
that there *is* some utility offered by this code which is not obvious
in the use cases I have: if this is the case, then a user could simply
turn on the function on a layer specific basis.
This needs to be resolved before the 2.3 release, or at least discussed
and the conclusion being "Leave it as is."
Personally, I'm in favor of (in descending order):
1. Removing the code. It hides errors, it doesn't fix them, and I dont'
think it's neccesary, even though I used to think it was (and it
probably was until 2.3 because of other bugs in Grid.js)
2. Adding an OpenLayers.Layer option to use it or not use it, defualting
to off.
3. Adding an OpenLayers.Layer option to use it or not use it, defaulting
to on (maintains current behavior)
4. Leaving as is, where some browsers can't support relative paths, etc., and
punting to the next release on solving it.
Can I get a vote for 1, 2, 3 or 4? After 24 hours, I'll take this to
the PSC, and then we can move forward with the next 2.3 RC2, which has
been blocking on this issue.
Regards,
--
Christopher Schmidt
MetaCarta
More information about the Dev
mailing list