truff
commented
8 years ago I think the enable/disable service command adds unnecessary complexity. Visibility of each layer in the capabilities document can already be toggled and the entire capabilities doc can be removed. That seems sufficient. Also, many maps will not support disabling of the ability for the user to show a layer that is in the layer tree, so supporting this type of functionality could be onerous.
Is overlayId from map.services.wms.add command the identifier for the wms service being added, or is it the parentOverlayId? I think we need both actually. But why isn't overlayId used in showlayers/hidelayers to specify the wms service instead of the url? I think it's better to use overlayId when referring to the service in the show/hide layers commands. Not because it ever makes sense to add the same service twice, but because comparing IDs is less error prone than comparing urls.
New channels can be added to enable addition of common geospatial services such as WMS, WMTS, TMS
WMS Example: map.services.wms.add - add service to map. If service with url already exists, treat as a refresh, remove current WMS, get the capabilities again { name: "Example Name", url: "http://wmsserviceurlhere", enabled: true, defaultLayerNames : ["layer1","layer2"], overlayId: "f324r-gfwf342g-wq34w-w34tg" } map.services.wms.remove - removes the service from map { url: "http://wmsserviceurlhere" } map.services.wms.enable - Turns service back on with previously selected layers active { url: "http://wmsserviceurlhere" } map.services.wms.disable - Allows developer to disable the entire service { url: "http://wmsserviceurlhere" } map.services.wms.showlayers - Allows developer to show on or more layers from service { url: "http://wmsserviceurlhere", lyerNames: ["layer1","layer2"] } map.services.wms.hidelayers - Allows developer to hide one or more layers from service { url: "http://wmsserviceurlhere", lyerNames: ["layer1","layer2"] }