using javascript functions in config-json

[atlefren]

the style attribute of a "GeoJSON" layer expects a JavaScript function for styling.

The JSON format does not include javascript function definitions, this means that the "JSON" needed by this lib is actually not JSON according to spec. This could cause trouble when storing this config in a json-aware database or when parsing/creating this config in another programming language.

Should probably find a way to express the style as pure JSON.

[robpvn]

Worth noting that since GeoJSON extends FeatureGroup, the setStyle function that accepts Path options is available (can use pure JSON), so the only need for the style attribute is when you want to style dynamically based on GeoJSON contents. (Which admittedly can be quite often when you're using geoJSON.)

[atlefren]

Guess I'm just grumpy then ;)

My main point is that since this lib uses a config that looks a lot like JSON it should be valid json in all cases, not 99% of the cases.

I haven't tested, but I would guess that some tools that works with JSON would choke on {"style": function (a) {return a;}}, as this isn't JSON.

I would rather prefer a more "complicated" style object that this lib would translate to a function if needed (maybe a JSON-variant of cartoCSS?)

[alexanno]

Interesting discussion! I partly agree with you Atle. It is not kosher to bring in JS in a JSON-string. However, the function definition in the "style" attribute should actually be defined as a string with escaped characters - ref the example in readme.md.

My suggestion is to not allow a direct function definition, but allow:

1. define a static style object (which could be packed into a function call on parsing)
2. refer to a function which should be called (need to be accessible at call time for Leaflet.)

[atlefren]

ah, my bad then, there is indeed an escaped string, so valid JSON at least.

But: this means that the library has to use "eval", which the method _evalJsonOptions does. According to Crockford and others "eval is evil" (https://jslinterrors.com/eval-is-evil), most important here is the security-issues this raises.

I kinda have mixed feelings for option 2, as this forces some constraints on how the config can be used, but nevertheless, it's better than in-lining the function and eval'ing it.

No love for my idea of parsing cartoCSS or SLD? ;)

[atlefren]

btw: one of the reasons for this interest is that i've forked a ol3-centered config-library (https://github.com/atlefren/BBol3) and thought it would have been cool to be able to re-use much of the same config format as this library