Drawfeatures behavior utilizes single global variable for every behavior instance. [#802042]

Comment	File	Size	Author
#8	DropGlobalVariable3.diff	3.44 KB	strk

#7	DropGlobalVariable2.diff	2.45 KB	strk

	DropGlobalVariable.diff	1.97 KB	strk

Comment #1

strk CreditAttribution: strk commented 18 May 2010 at 11:10

Patch was proved incomplete, there are still issues.

Log in or register to post comments

Comment #2

zzolo CreditAttribution: zzolo commented 18 May 2010 at 11:25

Title:

[PATCH] Drop global variable use in drawfeatures behaviour

» Drawfeatures behavior utilizes single global variable for every behavior instance.

It might be easier, though not as elegant to just use a global array to track elements by map id.

Also, calrity of issue. The openlayers_behavior_drawfeatures behavior utilizes a global variable to store the element ID that it refers to. This is not good if there are two maps that use this behavior with different elementIDs.

Log in or register to post comments

Comment #3

strk CreditAttribution: strk commented 19 May 2010 at 06:54

Note that I belive my previous patch is correct, only there are more globals in use.
Specifically I do see a 'features' and an 'wkt' variable in the DOM using firebug.

Log in or register to post comments

Comment #4

strk CreditAttribution: strk commented 19 May 2010 at 07:39

Even dropping the use of global 'feature' the generated HTML still contains a duplicated code for the "Data Layer" features.
Here's an excerpt:

CCBYSA<\/a> 2010\n OpenStreetMap.org<\/a> contributors","projection":["900913"],"layer_type":"openlayers_layer_type_xyz","url":"http:\/\/tile.openstreetmap.org\/${z}\/${x}\/${y}.png","serverResolutions":[156543.0339,78271.51695,39135.758475,19567.8792375,9783.93961875,4891.969809375,2445.9849046875,1222.9924523438,611.49622617188,305.74811308594,152.87405654297,76.437028271484,38.218514135742,19.109257067871,9.5546285339355,4.7773142669678,2.3886571334839,1.1943285667419,0.59716428337097],"maxExtent":[-20037508,-20037508,20037508,20037508],"layer_handler":"xyz","title":"OSM Mapnik"}},"id":"openlayers-cck-widget-map-field_wkt","styles":[],"layer_styles":[],"errors":false}; //--> CCBYSA<\/a> 2010\n OpenStreetMap.org<\/a> contributors","projection":["900913"],"layer_type":"openlayers_layer_type_xyz","url":"http:\/\/tile.openstreetmap.org\/${z}\/${x}\/${y}.png","serverResolutions":[156543.0339,78271.51695,39135.758475,19567.8792375,9783.93961875,4891.969809375,2445.9849046875,1222.9924523438,611.49622617188,305.74811308594,152.87405654297,76.437028271484,38.218514135742,19.109257067871,9.5546285339355,4.7773142669678,2.3886571334839,1.1943285667419,0.59716428337097],"maxExtent":[-20037508,-20037508,20037508,20037508],"layer_handler":"xyz","title":"OSM Mapnik"}},"id":"openlayers-cck-widget-map-field_wkt2","styles":[],"layer_styles":[],"errors":false}; //-->

Note the "features"."wkt"
The actual WKT values are different for the two fields, but in javascript they are seen as the same one (the first value computed prevails).

Log in or register to post comments

Comment #5

strk CreditAttribution: strk commented 19 May 2010 at 08:02

OOps, content was mangled.

Ok, the thing is that the following snippet is the same for both

Drupal.settings.openlayers.maps["openlayers-cck-widget-map-field_wkt"]

and

Drupal.settings.openlayers.maps["openlayers-cck-widget-map-field_wkt"]

Snippet:

"openlayers_cck_vector_layer":{"features":[{"wkt":"GEOMETRYCOLLECTION(LINESTRING(3.1640624998737 28.921631281365,34.80468749861 27.683528082769))","projection":"4326"}]}

Log in or register to post comments

Comment #6

strk CreditAttribution: strk commented 19 May 2010 at 08:03

Gah, sorry again messed up, the second options are for:
Drupal.settings.openlayers.maps["openlayers-cck-widget-map-field_wkt2"]

So, for field named 'wkt' and field named 'wkt2' the settings contain the same "openlayers_cck_vector_layer" behaviour options.

Log in or register to post comments

Comment #7

strk CreditAttribution: strk commented 19 May 2010 at 15:05

File	Size
DropGlobalVariable2.diff	2.45 KB

Let's forget about the second issue (the double layer on edit). That was fixed after a fresh db install (who knows what).
This issue here was about the global variable and that one I confirm is fixed by my patch.

Actually I attach an updated version of the patch which also gets rid of another 2 global variables.
These 2 didn't result in visible bugs for me, the globals were just bugging me in firebug DOM explorer...

To confirm the patch is good try to edit a node with 2 WKT fields.
W/out the patch it won't work correctly .