Loading a mapfile from a string...

[Steve Lime]

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...)
>>