[Mapserver-dev] Fwd: [Bug 358] New: RFE: refactor MapScript object constructors and containership methods
sgillies at frii.com
Wed Jul 9 16:33:54 EDT 2003
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.
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
> 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:
> 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
> or a filehandle
> fh = open('/path/to/some/map/file.map', 'w')
> 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
> 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
> 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.
sgillies at frii dot com
More information about the mapserver-dev