[Mapserver-dev] Fwd: [Bug 358] New: RFE: refactor MapScript object constructors and containership methods

[Sean Gillies]

I'm really on a roll today with the RFEs, though my
grammar could use a little work.

If you're interested in this one, which complements #357,
please add yourself to the cc: list.  I hope that my
Python bias in the examples doesn't offend.

cheers,
Sean

Begin forwarded message:

> From: bugzilla-daemon at lists.gis.umn.edu
> Date: Wed Jul 9, 2003  2:00:29  PM America/Denver
> To: sgillies at frii.com
> Subject: [Bug 358] New: RFE: refactor MapScript object constructors 
> and containership methods
>
> http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=358
>
>            Summary: RFE: refactor MapScript object constructors and
>                     containership methods
>            Product: MapServer
>            Version: 4.1
>           Platform: All
>         OS/Version: All
>             Status: NEW
>           Severity: enhancement
>           Priority: P2
>          Component: MapScript
>         AssignedTo: steve.lime at dnr.state.mn.us
>         ReportedBy: sgillies at frii.com
>
>
> This "bug" supercedes bug 132.
>
> Proposal for 4.1:
> that MapScript objects be refactored so that they
> can be instantiated from strings and write themselves out
> as strings.  Refactor the way in which objects contain child
> objects to make it more useful and robust.  This functionality
> would depend on the resolution of bug 357:
>
> http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=357
>
> Peudocode will be used to illustrate the proposal.  Well,
> Python, which is "executable pseudocode"(tm).
>
> Currently we can create a new map object by using a filename
> of a map file
>
>    mapobj = mapObj('/path/to/some/map/file.map')
>
> or from an empty string
>
>    mapobj = mapObj('')
>
> We shall be able to equally use file handles
>
>    fh = open('/path/to/some/map/file.map', 'r')
>    mapobj = mapObj(fh)
>
> or text strings
>
>    map_def = 'MAP\nNAME "foo"\nHEIGHT 400\nWIDTH 400\n...END'
>    mapobj = mapObj(map_def)
>
> as arguments to the object constructor.  Note that we should
> not rule out the possibility of using XML as an argument, but
> I do not want the issue of an XML map file to in any way
> encumber this particular proposal.
>
> Objects shall be able to save a representation
> of themselves to a stream which is specified by a filename
>
>    mapobj.save('/path/to/some/map/file.map')
>
> or a filehandle
>
>    fh = open('/path/to/some/map/file.map', 'w')
>    mapobj.save(fh)
>
> Additionally, objects shall be able to return a string
> representation of themselves using a method named 'toString'
>
>    map_def = mapobj.toString()
>
> The value returned by toString() can be used to create new
> objects
>
>    mapobj_copy = mapObj(mapobj.toString())
>
> Likewise, this new features shall extend to all mapping objects
> so that we can create new layers like
>
>    layer_def = 'LAYER\nNAME "new_layer"\n...END'
>    layerobj = layerObj(layer_def)
>
> It is further proposed that a layerObj (or classObj) may exist
> outside of the context of a map and that the proper way to
> put it into a map is the use of a method called 'appendLayer'
> (Note: I've borrowed the name of this method from the W3C's
> DOM specification, but changed it from 'appendChild' to
> 'appendLayer')
>
>    mapobj.appendLayer(layerobj)
>
> To complement appendLayer() there shall be a method named
> 'removeLayer' which removes a layer from a map and returns
> the layer object
>
>    layerobj = mapobj.getLayer(0)
>    removed_layerobj = mapobj.removeLayer(layerobj)
>
> We shall implement corresponding appendClass() and
> removeClass() methods for layer objects.
>
> This won't be very hard to implement, but as the new
> constructors and append* methods will break existing
> scripts, I'd like to get some comments on this
> proposal.  I'm certain that the benefits of the new
> constructors will outweigh the inconveniences of
> updating scripts.
>
>
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>
>
--
Sean Gillies
sgillies at frii dot com
http://www.frii.com/~sgillies