QooxDoo: launch source version with denwer
QooxDoo is a fairly well-developed JS-library for developing RIA (Rich Internet Applications). I will not go into details of the library and describe where my legs grow from. Who faced the problem - he will understand what's what.
So. The problem is that the source-version of the application, in the form in which the compiler collects it, does not start from the web server (emulates denwer) but only as a local file.
In other words:
_C: /WebServers/home/localhost/www/app/index.html - starts
_http: // localhost / app - DOES NOT start
This leads to the fact that the usual AJAX requests do not work in the source-version (for cross-domain work, you have to use JSON-P), and also the work with external flash objects does not work (just the problem with domains). Although as a result, the build version works without problems.
By experiments, a solution was found. The essence is the use of absolute links to files instead of relative links when creating an application skeleton. The solution is to replace the path in the QOOXDOO_PATH variable in “c: / your_path” with something like “../../your_path” in config.json. BUT! It should be remembered that the directory of the qooxdoo itself, which this path will point to, should also be in the directory structure of the Denver (that is, on the Z virtual disk itself, or whatever you called it during installation). Otherwise, Denver will not pick up the link.
')
The generate.py script also has a path to the qooxdoo distribution, but in this case, the relative path is not critical - the python also compiles scripts with absolute paths.
In addition, as far as I managed to find out, the source version will not work with external libraries. At least, when trying to connect via jobs to work with the external interface for the Open Flash Chart, the source did not want to work, while the build worked fine. External connection had to be replaced by the introduction of interface classes inside the application.
UPD : The source-version launched from the server pulls in separate requests all, as I understand it, the affected classes-js_files. If firebug is turned on in the window, it easily hangs the baruser. It helps to disable the network panel at the time of launch.
So. The problem is that the source-version of the application, in the form in which the compiler collects it, does not start from the web server (emulates denwer) but only as a local file.
In other words:
_C: /WebServers/home/localhost/www/app/index.html - starts
_http: // localhost / app - DOES NOT start
This leads to the fact that the usual AJAX requests do not work in the source-version (for cross-domain work, you have to use JSON-P), and also the work with external flash objects does not work (just the problem with domains). Although as a result, the build version works without problems.
By experiments, a solution was found. The essence is the use of absolute links to files instead of relative links when creating an application skeleton. The solution is to replace the path in the QOOXDOO_PATH variable in “c: / your_path” with something like “../../your_path” in config.json. BUT! It should be remembered that the directory of the qooxdoo itself, which this path will point to, should also be in the directory structure of the Denver (that is, on the Z virtual disk itself, or whatever you called it during installation). Otherwise, Denver will not pick up the link.
')
The generate.py script also has a path to the qooxdoo distribution, but in this case, the relative path is not critical - the python also compiles scripts with absolute paths.
In addition, as far as I managed to find out, the source version will not work with external libraries. At least, when trying to connect via jobs to work with the external interface for the Open Flash Chart, the source did not want to work, while the build worked fine. External connection had to be replaced by the introduction of interface classes inside the application.
UPD : The source-version launched from the server pulls in separate requests all, as I understand it, the affected classes-js_files. If firebug is turned on in the window, it easily hangs the baruser. It helps to disable the network panel at the time of launch.
Source: https://habr.com/ru/post/106930/
All Articles