Loading a mapfile from a string...

[Steve Lime]

Actually I think it can. We could create a new tokenizer mode that would allow us to 
recognize only the tokens we want to allow from a URL. Could use the same loadXXXXX
functions but only select parameters could be set. For example, you can't change a
layer name, data, connection, connectiontype and so on.

I see there is a bug for this functionality now. How about starting an RFC?

Steve

>>> Sean Gillies <sgillies at FRII.COM> 04/27/07 2:03 PM >>>
An update() would work for me. On the other hand, I don't like scripting 
through the query string at all, and hope that the implementation of 
update could be separated from any mapserv.exe concerns.

Sean

Steve Lime wrote:
> I was thinking of  re-doing the msLoadLayerString type functions (I renamed those
> msLoadLayerValue for now cause all they do is load 1 value). Basically I was along the same
> lines as yourself, but wouldn't require the wrapping tags (LAYER, END) although that could
> be dealt with (e.g. the token LAYER is valid in a layerObj). The object identifier token is detected
> in the parent object (e.g. a LAYER in a MAP) .The idea being that we could use  1 set of msLoad... 
> functions for everything.
> 
> As a result, Sean's scenario would work, as would:
> 
>   $layer->update("...snippet..");
> 
> Via a URL, we could do away with:
> 
> map_scalebar_units=METERS&map_scalebar_intervals=5...
> 
> and just do:
> 
> mapstring=SCALEBAR+UNITS+METERS+INTERVALS+SIZE+4+END
> 
> With LAYERS you'd send the NAME and if a layer already exists with that name you'd be updating
> an existing object. Same thing with a class I guess?
> 
> The big issue from a URL is not allowing just anything to be overridden. Right now there is a separate,
>  very duplicative set of code for each object (e.g. msLoadLayerValue) so we can place limits on what can 
> be set. I'm sure this can be worked around.
> 
> Steve
> 
>>>> On 4/27/2007 at 10:20 AM, in message <463214AA.2070501 at frii.com>, Sean Gillies
> <sgillies at FRII.COM> wrote:
>> Steve,
>>
>> I'm fine with a requirement for modern flex. Maybe we could take 
>> advantage of the svn post-commit hooks to make mapparser.c and 
>> maplexer.c whenever the ultimate source changes. That would allow 
>> windows folks (bless their hearts) to experiment with the trunk.
>>
>> Isn't there also a msLoadLayerString too? What would you think about an 
>> abstract factory function in mapscript that returned an object 
>> corresponding to the block you pass in?
>>
>>    map = mapscript.load("MAP ... END")      # returns mapObj
>>    layer = mapscript.load("LAYER ... END")  # returns layerObj
>>
>> Sean
>>
>> Steve Lime wrote:
>>> Only one comment (and positive at that) so... this has been commited. One =
>>> caveat is that to avoid leaking memory yylex_destroy is being used to =
>>> clean things up. Apparently this is available in newer versions of flex. =
>>> May actually be there in old versions but only if a reentrant scanner is =
>>> being built. Presents a small problem. We can control the distributions by =
>>> using a newish version of flex when building things for users. Requiring =
>>> developers to use version x.x.x (I'm at 2.5.31) doesn't seem to big a =
>>> hardship. Thoughts?
>>>
>>> Steve
>>>
>>>>>> Steve Lime <Steve.Lime at DNR.STATE.MN.US> 04/17/07 11:28 PM >>>
>>> Hi Folks: I've been screwing around with getting mapserver to ingest a =
>>> mapfile stored in a string buffer rather than a file. In theory you could =
>>> build up a configuration from text snippets or database output rather than =
>>> manipulating objects directly. The code could almost do this in the past =
>>> but needed some reorganization to re-use as much as possible. The result =
>>> is a new function called msLoadMapFromString. I took the opportunity to =
>>> fix some naming wierdness in mapfile.c and to clean up lexer initialization=
>>>  a bit. In otherwords I'm sitting on a fair number of minor changes to =
>>> mapfile.c and maplexer.l (with a few other small edits elsewhere). Is this =
>>> a big enough deal to warrant a RFC or can I just commit?
>>>
>>> Steve
>>>
>>> BTW A sample perl snippet might look like (mapscript integration isn't =
>>> part of these changes other than exposing the function):
>>>
>>> $buffer =3D "MAP ... END";
>>> $map =3D $mapscript::msLoadMapFromString($buffer, undef); # takes the =
>>> buffer and an optional directory (location of symbols...)
>>>
> 
> 


-- 
Sean Gillies
http://zcologia.com/news