First off, I apologize for missing the meeting this morning, I completely forgot about it.
The intent of the OWSExplorer demo is to point to a WMS and/or WFS instance and see what layers and feature types are available and visualizing them on the map. It is set up by default to look for a GeoServer instance at /geoserver/wms, ie. on the same machine as the demo is running so if there is no /geoserver available, it won't work until you put a different capabilities URL in. I think it's worth keeping because it allows exploration of WMS/WFS and was originally intended as a better layer preview client for GeoServer. Perhaps it should by default point to a network instance rather than localhost, but it does work as intended. As for GetFeatureInfo, mapViewer and OWSExplorer demos use a different implementation than lib/widget/GetFeatureInfo because at the time I wanted to implement that using the WebServiceRequest tool. This is a little more consistent with the MVC design pattern using the tool to generate requests rather than doing that in the widget. However I'm not sure that the WebServiceRequest tool is getting much traction in general and there is a few instances where MVC isn't strictly followed anyway. In my mind that is the preferred way to generate web service requests because the one tool can generate all sorts of different requests just by adding tool/xsl stylesheets that process capabilities (or other) documents. So I guess my question is shouldn't we use the mapViewer/GetFeatureInfo.js rather than the lib/widgetGetFeatureInfo version? The hard-coded reference to the response model can be fixed. Mike Andreas Hocevar wrote: > To clarify another question from today's meeting: > > demo/mapViewer/GetFeatureInfo.js can be replaced by > lib/widget/GetFeatureInfo.js. I just tried both in the mapViewer > example, and both work. Only the widget config parameters are > different: demo/mapViewer/GetFeatureInfo.js takes the map in the > targetModel parameter, whereas lib/Widget/GetFeatureInfo.js expects > the featureInfoResponse model in the targetModel parameter. The reason > for this is that the featureInfoResponse model is hard-coded in > demo/mapViewer/GetFeatureInfo.js. > > Regards, > Andreas. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > mapbuilder-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel > > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ mapbuilder-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel
