[Mapbender-dev] Element Vars and types of variables

Christoph Baudson (WhereGroup) christoph.baudson at wheregroup.com
Thu Nov 8 07:53:56 EST 2007

Marc Jansen schrieb:
> Hi list,
> is it true that all element variables are considered to be of type 
> string? Wouldn't it be nice if we could have some different types of 
> element vars (at least for javascript variables )?
Indeed, it would be nice. At the moment devs should do a type check 
anyway in the script that reads the variable, and it is problematic due 
to ambiguity.
> IMHO this would require an additional database column and an update of 
> the existing vars. As for backwards compatibility the default type 
> could be 'string', I guess.
> I'd suggest haveing at least these types:
>    * string        * integer      * float          * array        * 
> object
>    * boolean

Maybe integer and float could be the same type, "numeric" for example.

> consider boolean setting for modules, they should be interpretebable 
> as booleans, or consider having more variable that are variants of 
> equal properties (tabs module). I found my self fuddling with stuff 
> like this:
> element_var = "opt1,opt2,foo,bar,baz";
> element_var_as_array = element_var.split(',');
> another_var_which_represents_a_boolean = 'true';
> another_var_as_boolean = ( 
> another_var_which_represents_a_boolean.toLowerCase() == 'true' ) ? 
> true : false;
> This is in my opinion error prone, time consuming (performance) and 
> not elegant. Or am I missing something in the concept of element vars?
The only argument I remember was, that administrators may not be 
familiar with these types, and the interface would become more 
complicated. But I would prefer to trade some usability for type safety.

We could enhance the form for element vars, by adding type checks, and 
by having radio buttons for booleans.

Maybe we could also think about adding the expected variables (with 
additional information like mandatory, optional, range etc.) in the 
database somewhere, so the validity check could be done in a seperate 
class, and not over and over again in each script (which is time 
consuming and easily done too sloppy...a lot of errors in Mapbender stem 
from misconfigured element vars).

> What do you think?

Good idea, do you plan to do development on this? If yes, I can support you.

> _______________________________________________
> Mapbender_dev mailing list
> Mapbender_dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapbender_dev

Die Lösungskonferenz der WhereGroup
am 29. November 2007 in Bonn

W h e r e G r o u p GmbH & Co. KG

Siemensstraße 8
53121 Bonn

Christoph Baudson

Fon: +49 (0)228 / 90 90 38 - 17
Fax: +49 (0)228 / 90 90 38 - 11
olaf.knopp at wheregroup.com
Amtsgericht Bonn, HRA 6788

WhereGroup Verwaltungs GmbH
vertreten durch:
Arnulf Christl, Olaf Knopp, Peter Stamm

More information about the Mapbender_dev mailing list