It happens that isBaseLayer gets to be a string rather than a bool.
This breaks some GeoExt (and I'm sure will break OL too one day, when performance tweaks are in, as === is faster than ==).

So, tracking this back seems to suggest the string originates from a #return_vaulue = 'true' in wms.inc forms.
Why was it made so ?

I'd cast to bool on use, to support old exportables, but I think we'd need a way for exportables to be checked before being
written in DB, to do these kind of cleanups in an easier way.

Comments

strk’s picture

I found out that #return_value type was changed by commit http://drupal.org/cvs?commit=408332
performed by tmwc. Patch came from batje in http://drupal.org/node/878644

strk’s picture

The rationale for that #return_value change is reported to be here: http://drupal.org/node/862690

strk’s picture

Commit http://drupal.org/cvs?commit=423660 casts isBaseLayer to boolean before sending to javascript, so to support ruined layer exportables produced after commit http://drupal.org/cvs?commit=408332

Next I'd like to revert the portion of commit 408332 which had nothing to do with the issue the commit references, that
is the #return_value thing.

strk’s picture

Note that http://drupal.org/node/862690, referenced by http://drupal.org/node/878644 to justify the #return_value change,
is closed by commit http://drupal.org/cvs?commit=403394 which actually _introduced_ #return_value with proper value (TRUE)
http://drupalcode.org/viewvc/drupal/contributions/modules/openlayers/inc...

So, there's where I'll put the code again.
Writing malformed exportables is a very bad idea.

In addition to the cast, if we want to support a migration from old exportables to new ones, we might need
to also apply the cast to every use of old presets (annoying)

strk’s picture

Status: Active » Fixed

Committed the #return_value revert in http://drupal.org/cvs?commit=423674

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.