1.1 --- a/README.txt Fri Jul 22 21:00:31 2005 +0000
1.2 +++ b/README.txt Fri Jul 22 21:34:01 2005 +0000
1.3 @@ -36,38 +36,44 @@
1.4 ------- -------------------
1.5
1.6 libxml2dom 0.2
1.7 -libxml2 2.6.16
1.8 -libxslt 1.1.12
1.9 +libxml2 Tested with 2.6.17
1.10 +libxslt Tested with 1.1.12
1.11
1.12 The example Web applications require WebStack (release 0.10 or later).
1.13
1.14 Notes on In-Page Update Functionality
1.15 -------------------------------------
1.16
1.17 -Special note: Konqueror seems to remember replaced form content (when
1.18 -replaceChild is used to replace regions of the page which include form
1.19 -elements). This causes the browser to believe that more form fields exist on
1.20 -the page than actually do so, and subsequent form submissions thus include the
1.21 -values of such removed fields. A special hack is in place to disable form
1.22 -fields by changing their names, thus causing Konqueror to not associate such
1.23 -fields with the real, active fields; this hack does not seem to cause problems
1.24 -for Mozilla.
1.25 +Special note #1: Konqueror seems in certain cases to remember replaced form
1.26 +content (when replaceChild is used to replace regions of the page which
1.27 +include form elements). This causes the browser to believe that more form
1.28 +fields exist on the page than actually do so, and subsequent form submissions
1.29 +thus include the values of such removed fields. A special hack is in place to
1.30 +disable form fields by changing their names, thus causing Konqueror to not
1.31 +associate such fields with the real, active fields; this hack does not seem to
1.32 +cause problems for Mozilla. This needs some investigation to determine in
1.33 +exactly which circumstances the problem arises.
1.34 +
1.35 +Special note #2: Konqueror also seems to crash if asked to find elements using
1.36 +an empty 'id' attribute string. This needs some investigation to see if it
1.37 +really is the getElementById call that causes the crash.
1.38
1.39 Various browsers (eg. Mozilla/Firefox, Konqueror) will not allow the
1.40 -XMLHttpRequest in-page updates to function unless the application URL defined
1.41 -within the Configurator application (and other relevant applications) matches
1.42 -the URL at which the browser finds the application. This URL is deduced by the
1.43 -various applications using the WebStack API, but it is possible that the
1.44 -values returned by that API do not match the actual addresses entered into the
1.45 -address bar of the browser.
1.46 +XMLHttpRequest in-page updates to function unless the URL used in the
1.47 +requestUpdate JavaScript function is compatible with the URL at which the
1.48 +browser finds the application. Currently, relative URLs are in use to avoid
1.49 +this issue of compatibility, but should an absolute URL be deduced using the
1.50 +WebStack API and then used, it may be possible that the values returned by
1.51 +that API do not match the actual addresses entered into the address bar of the
1.52 +browser.
1.53
1.54 To check the behaviour of the applications, it is possible to view the
1.55 document source of the pages served by applications and to verify that the
1.56 -URLs mentioned in the JavaScript function calls (to 'requestUpdate') involve a
1.57 -URL similar to that which appears in the browser's address bar. In some
1.58 -environments, the use of 'localhost' addresses often confuses the browser and
1.59 -server; one workaround is to use real host names or addresses instead of
1.60 -'localhost'.
1.61 +URLs mentioned in the JavaScript function calls (to 'requestUpdate') either be
1.62 +a relative link or involve a URL similar to that which appears in the
1.63 +browser's address bar. In some environments, the use of 'localhost' addresses
1.64 +often confuses the browser and server; one workaround is to use real host
1.65 +names or addresses instead of 'localhost'.
1.66
1.67 Choosing an element-path:
1.68
