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

[Stephen Woodbridge]

As much as I hate to potentially make this more complicated, this also 
reminds me that we can read/write mapfile as text. So if one wants to be 
able to read a mapfile make changes to is in mapscript and then save it 
back out to a mapfile again this will not be achievable unless we 
support access to the structures in mapscript.

I think this is the use case that demands this. I'm sorry I did not 
think of this earlier.

How are you representing this internally?
Is there some kind of object that we need/could expose to mapscript?

Thanks,
   -SteveW

On 12/14/2012 1:16 PM, Daniel Morissette wrote:
> I object.  :)
>
> 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.
>
> 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.
>
> 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
>>
>
>