Mike, On 7/31/07, Mike Adair <[EMAIL PROTECTED]> wrote: > 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.
I agree with you that using the WebServiceRequest tool for requests is the cleaner way. And as I said in the meeting today, I have the impression that demo/mapViewer/GetFeatureInfo.js is more mature than lib/Widget/GetFeatureInfo.js. My opinion is definitely to use the demo/mapViewer/GetFeatureInfo.js. Besides fixing the thing with the hard-coded reference to the response model, it might also be wise to use the OpenLayers box handler for selecting features, in case someone wants to do queries based on a rectangle and not just a point. 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
