You need to log in before you can comment on or make changes to this bug.
There is a problem with unexpected zooming to full extents in the IOOS application. The app uses cwc2 1.0.4. Here are the steps to reproduce: -Launch application (http://www.mapsherpa.com/ioos/) -Zoom in anywhere -Do a point query -Change any element in the Time Filter -Click Apply button in Time Filter The map will zoom to full extents.
I thought I had reproduced this problem but it turns out that I didn't, and I cannot seem to at all now. One note. The timefilter widget does submit the page, and because the template form has no method set, it uses "get" by default. One potential cause of this problem could be related to use of "get" in Internet Explorer, which has a tendency to truncate the URL ... so try changing the template form to method="post" and see what happens :)
Too late! You already admitted that you reproduced it.
all right, I can reproduce it now using: http://www2.dmsolutions.ca/msapps/cwc2-snap-20031210/cwc2.php?template=http://www2.dmsolutions.ca/msapps/ioos/ioos.html&context=http://www2.dmsolutions.ca/msapps/ioos/ioos_prototype.xml
Has there been any progress on this bug? I hate to be a nag but this bug presents a major usability issue in the IOOS demo application and really should be fixed. It may also affect any number of other CWC2 applications out there.
I dug into this bug briefly but was not able to find the problem. My best guess right now is that the time filter (and legend for that matter) submit the page. This only happens because the app is using the JSAPI mode. I thought that the reason was that the map extents were not being set in the page by the navigation widgets (only in the javascript objects), and when the page submitted, it would return to full extents. This does not seem to be the case, although I did not have time to fully test my theory. can this be coded to IOOS?
Paul, Your theory is sound. Should we just update the timefilter to work in JSAPI mode as a fix for now? I suppose the better fix would be to have better communication between JSAPI mode and page submits. We should not have to be restricted to only using JSAPI enabled widgets when we use JSAPI mode.
I did try to fix this in the cwcjsapi.js file by also updating the document form variables when the extents change, but that didn't seem to solve the problem, although there may have been some caching involved. I'll be taking a closer look at this today (hopefully)
this actually works out to be three separate issues that all needed to be resolved. First, the jsapi javascript was not updating the extents of the map in the document's form so when the page was submitted by a non-jsapi widget (like UpdateMap), this caused the map to revert to its original extents. Second, when this was fixed, the page would then resubmit the previously used navigation command, so this is now cleared when the map extents are updated to prevent the operation from happening a second time if the page is submitted after zooming in (for instance). The final issue is that POST support had been broken when we modified the code to allow for multiple templates coming via the URL, but this requires parsing the QUERY_STRING value (the part in the URL after the ?) which is how GET works. Apparently POST variables are not considered part of the QUERY_STRING so using POST as the form method in any CWC2 application will not work until I commit these fixes. Which I am doing now :) I will also try to fix bug 159 before releasing a new version.
fixed in chameleon 1.0.6 available from: http://www.maptools.org/dl/chameleon/chameleon-1.0.6-20031222.tar.gz http://www.maptools.org/dl/chameleon/chameleon-1.0.6-20031222.zip
