[mapserver-dev] Scale Dependent Token Replacements: to mapscript or not to mapscript

[thomas bonfort]

On Fri, Dec 14, 2012 at 7:16 PM, Daniel Morissette <dmorissette at mapgears.com
> wrote:

> I object.  :)
>
Yes, I somewhat expected you to react :)


> I agree with Worth that this should be supported in MapScript otherwise
> skipping features like this would mean that over time MapScript will become
> a second class citizen.

/me refrains from commenting :)


>
> Even if it is possible in theory to do the same thing in MapScript with
> custom code, RFC-86 proposes a nice way to handle a common need directly in
> the mapfile without custom coding, and my opinion is that a given mapfile
> should work the same way when rendered through the mapserv CGI as when it
> is rendered through MapScript. A generic MapScript app should be able to
> open any mapfile built for the CGI and render it without requiring custom
> code.
>

The token replacements occur at rendering time, and thus would be applied
indifferently if the rendering was initiated through mapscript or a cgi.
What I'm questioning is the relevance of adding mapscript getters and
setters to the scaletokens, as when you are using mapscript it is much
simpler/direct to modify the layer.data directly. Again, please come up
with a use-case for accessing scaletokens in mapscript, as for now I
believe that adding them would be a waste of time/effort for a feature that
would never be used.

--
Thomas


> Are the scaletokens processed at rendering time in your implementation? If
> yes then it should not be that hard to support it in MapScript, or is there
> some blocker that we are not aware of?
>
> My 0.02$
>
> Daniel
>
>
> On 12-12-14 3:41 AM, thomas bonfort wrote:
>
>> Devs,
>>
>> There's a point that I overlooked when submitting RFC86, which concerns
>> exposing the scale dependent token mechanism to mapscript.
>>
>> I'd argue that the whole point of the RFC is to simplify mapfile
>> management thus avoiding the use of mapscript in a number of cases, and
>> that there is no real usecase in exposing this API to mapscript (as a
>> mapscript script can do these replacements directly on the layer's
>> data/filter).
>> If there is no objection, I will amend the mapscript part of the RFC to
>> state: "Given the more straightforward methods to obtain the same
>> results as this RFC in mapscript, access to a layer's SCALETOKENs will
>>   not be exposed to mapscript for the time being".
>>
>> So, are there any objections? :)
>>
>> cheers,
>> thomas
>>
>>
>> ______________________________**_________________
>> mapserver-dev mailing list
>> mapserver-dev at lists.osgeo.org
>> http://lists.osgeo.org/**mailman/listinfo/mapserver-dev<http://lists.osgeo.org/mailman/listinfo/mapserver-dev>
>>
>>
>
> --
> Daniel Morissette
> http://www.mapgears.com/
> Provider of Professional MapServer Support since 2000
>
> ______________________________**_________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/**mailman/listinfo/mapserver-dev<http://lists.osgeo.org/mailman/listinfo/mapserver-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20121215/038e45bd/attachment.html>