IE6, but not FF3 or Opera9, error on loading blank GML layer

[CharlesHarrison]

Suppose you want to write a page where someone can add a few features into a layer, convert them into GML, and cut and paste the GML into a file. You need to start with a blank GML layer, and the only way I've discovered of doing this is to omit the source url. This works fine in FF3 and Opera9, but not in IE6.

If a blank GML layer (no source file url specified in the constructor) is loaded over a WMS layer of UK Ordnance Survey tiles, as here ...

 http://www.macfh.co.uk/Test/GMLIEBug_UKOS.html

... then IE6 throws an error. However, if only the line loading the blank GML layer is commented out (line 35 in this file), then there is no error. When a blank GML layer is loaded over, say, a Metacarta WMS layer, as here ...

 http://www.macfh.co.uk/Test/GMLIEBug_Metacarta.html

... sometimes there is an error, sometimes not, this page is producing one for me at the moment. When a source file is specified, IE6 doesn't throw an error even if the path is incorrect (though in that case OL throws up an alert).

On this first investigation, the error didn't seem to prevent subsequent functionality.

The error thrown is ...
Line: 731
Char: 78
Error: Object required
Code: 0
URL: <document.URL>
... though I suspect the line number refers to a different file, perhaps the OL source js, as is common with IE errors.

[ahocevar]

Please don't use the issue tracker for questions -- use the users mailing list instead.

The solution to your problem is simple. Use Layer.Vector instead of Layer.GML, and then use Format.GML to create your copyable GML snippet. You can see exactly how this works in  http://www.openlayers.org/dev/examples/vector-formats.html

[CharlesHarrison]

I seem to recall discovering that demo some while ago, and since your post have been re-exploring it. However, there is a crucial disadvantage to it in terms of what I am trying to do - you can only create new features or import others one at a time, you can't do that OR load an existing GML layer into it and add new features to it.

Also there is the point that the error only happens in IE, and not other browsers, suggesting that the OpenLayers.Request or OpenLayers.Request.XMLHttpRequest is failing to check for a blank or undefined URL on the legacy IE branch (legacy IE uses an ActiveX control to make the request, whereas more modern/standards compliant browsers uses a s standard DOM object). Hence this bit of code really needs to be updated to do nothing if the URL is blank, undefined, null, etc.

However, I can continue with my project because I've found a fix, redefining the layer's loadGML function to make the check before it does the call:

gmlLayer =
	new OpenLayers.Layer.GML
		(
			"GML Layer",
			undefined,
			{
				projection:	EPSG27700,
				loadGML:	function()
							{
							if(!this.loaded && this.url)
								{
								// etc.
								}
							}
			}
		);

[ahocevar]

• Doing a request without an URL makes absolutely no sense.
• Layer.GML is deprecated. Layer.Vector is the way you go. Use protocols and strategies to load features from and save features to servers. With strategies, you can control exactly if or when you want to load features.

[CharlesHarrison]

Replying to ahocevar:

* Doing a request without an URL makes absolutely no sense.

Exactly, so make the code more robust by trapping it!

* Layer.GML is deprecated. Layer.Vector is the way you go. Use protocols and strategies to load features from and save features to servers. With strategies, you can control exactly if or when you want to load features.

Fine, but how? I have searched the entire site for documentation and examples, and have found only lots of cryptic tickets. I have searched the first five pages of hits for Google: +"open layers" strategies protocols -svn -ticket. There is zilch documentation about this. I have not the faintest idea how to begin.

[CharlesHarrison]

Replying to CharlesHarrison:

Fine, but how? I have searched the entire site for documentation and examples, and have found only lots of cryptic tickets. I have searched the first five pages of hits for Google: +"open layers" strategies protocols -svn -ticket. There is zilch documentation about this. I have not the faintest idea how to begin.

And there is no mention of the word 'deprecated' on the OpenLayers.Layer.GML class library documentation page:

 http://dev.openlayers.org/releases/OpenLayers-2.8/doc/apidocs/files/OpenLayers/Layer/GML-js.html

[crschmidt]

The OpenLayers library does not have error checking set up for many of the cases where it could, because there are more silly things that users can do than we can possibly account for.

I have clarified this in the OpenLayes Syntax reference in the documentation: Specifically, if a parameter is allowed, it is generally required, unless it is the 'options' parameter. Beyond that, this is simply a usage error: The GML Layer constructor states that it requires a string. Trying to account for every case where someone does something other than that -- as is the case in these non-working examples -- would be a waste of time.

[CharlesHarrison]

Replying to crschmidt:

The OpenLayers library does not have error checking set up for many of the cases where it could, because there are more silly things that users can do than we can possibly account for.

If you built code from the ground up on the basis, the assumption in fact, that users will sometimes find what seems to them a very good reason to do something that seems 'silly' to you, then in time it would repay the investment, probably many times over, through your code being more robust and easier to maintain.

I note that you say nothing about strategies, protocols? Can you please clarify whether the GML layer is indeed deprecated, and if so, please can its documentation be updated accordingly, and alternative approaches be adequateley documented, and illustrated with examples?

[crschmidt]

I'm not making any comment on whether the GML layer is deprecated; it is irrelevant to the ticket. Whether the GML layer is deprecated or not, additional error checking of parameters is not something that we should add to just this code. If someone wishes to add such support throughout the library, a new ticket is appropriate. The fact that the library depends on users to use it as the documentation suggests is not a bug; it is a design decision, and therefore there is no need to change the behavior.

Changes to the library to improve error handling, error reporting, or other behaviors when users don't follow the documentation would be one thing; fixing a small behavior problem in one specific case without a more general approach or policy is unnecessary; arguing in favor of it is time wasted effort.