# HG changeset patch # User paulb # Date 1122068041 0 # Node ID b73bc13d53c0cb046cda7dedef8bf5f89e28af7f # Parent 8273532058560e70980ffb2125adfb476f04bcd0 [project @ 2005-07-22 21:34:01 by paulb] Updated tested versions of dependencies. Updated the notes on in-page updates and application URLs. diff -r 827353205856 -r b73bc13d53c0 README.txt --- a/README.txt Fri Jul 22 21:00:31 2005 +0000 +++ b/README.txt Fri Jul 22 21:34:01 2005 +0000 @@ -36,38 +36,44 @@ ------- ------------------- libxml2dom 0.2 -libxml2 2.6.16 -libxslt 1.1.12 +libxml2 Tested with 2.6.17 +libxslt Tested with 1.1.12 The example Web applications require WebStack (release 0.10 or later). Notes on In-Page Update Functionality ------------------------------------- -Special note: Konqueror seems to remember replaced form content (when -replaceChild is used to replace regions of the page which include form -elements). This causes the browser to believe that more form fields exist on -the page than actually do so, and subsequent form submissions thus include the -values of such removed fields. A special hack is in place to disable form -fields by changing their names, thus causing Konqueror to not associate such -fields with the real, active fields; this hack does not seem to cause problems -for Mozilla. +Special note #1: Konqueror seems in certain cases to remember replaced form +content (when replaceChild is used to replace regions of the page which +include form elements). This causes the browser to believe that more form +fields exist on the page than actually do so, and subsequent form submissions +thus include the values of such removed fields. A special hack is in place to +disable form fields by changing their names, thus causing Konqueror to not +associate such fields with the real, active fields; this hack does not seem to +cause problems for Mozilla. This needs some investigation to determine in +exactly which circumstances the problem arises. + +Special note #2: Konqueror also seems to crash if asked to find elements using +an empty 'id' attribute string. This needs some investigation to see if it +really is the getElementById call that causes the crash. Various browsers (eg. Mozilla/Firefox, Konqueror) will not allow the -XMLHttpRequest in-page updates to function unless the application URL defined -within the Configurator application (and other relevant applications) matches -the URL at which the browser finds the application. This URL is deduced by the -various applications using the WebStack API, but it is possible that the -values returned by that API do not match the actual addresses entered into the -address bar of the browser. +XMLHttpRequest in-page updates to function unless the URL used in the +requestUpdate JavaScript function is compatible with the URL at which the +browser finds the application. Currently, relative URLs are in use to avoid +this issue of compatibility, but should an absolute URL be deduced using the +WebStack API and then used, it may be possible that the values returned by +that API do not match the actual addresses entered into the address bar of the +browser. To check the behaviour of the applications, it is possible to view the document source of the pages served by applications and to verify that the -URLs mentioned in the JavaScript function calls (to 'requestUpdate') involve a -URL similar to that which appears in the browser's address bar. In some -environments, the use of 'localhost' addresses often confuses the browser and -server; one workaround is to use real host names or addresses instead of -'localhost'. +URLs mentioned in the JavaScript function calls (to 'requestUpdate') either be +a relative link or involve a URL similar to that which appears in the +browser's address bar. In some environments, the use of 'localhost' addresses +often confuses the browser and server; one workaround is to use real host +names or addresses instead of 'localhost'. Choosing an element-path: