QooxDoo：denwerでソースバージョンを起動

QooxDooは、RIA（Rich Internet Applications）を開発するためのかなりよく開発されたJSライブラリです。 ライブラリの詳細には触れず、足がどこから成長するかを説明しません。 問題に遭遇した人は何が何であるかを理解するでしょう。

など。 問題は、コンパイラが収集する形式のアプリケーションのソースバージョンがWebサーバーから起動せず（denwerをエミュレート）、ローカルファイルとしてのみ起動することです。



言い換えれば：

_C：/WebServers/home/localhost/www/app/index.html- 開始

_http：// localhost / app- 起動しません



これは、ソースバージョンでは通常のAJAXリクエストが機能しないという事実につながり（クロスドメインの作業ではJSON-Pを使用する必要があります）、外部フラッシュオブジェクトの使用も機能しません（ドメインの問題もあります）。 ただし、その結果、ビルドバージョンは問題なく機能します。



実験により、問題の解決策が見つかりました。 一番下の行は、アプリケーションスケルトンを作成するときに、相対リンクではなくファイルへの絶対リンクを使用することです。 解決策は、QOOXDOO_PATH変数のパスを「C：/ your_path」からアプリケーションconfig.jsonの「../../your_path」のようなものに置き換えることです。 しかし！ このパスが指すqooxdoo自体のディレクトリは、デンバーのディレクトリ構造（つまり、仮想ディスクZ自体、またはインストール中に呼び出したディレクトリ）にも存在する必要があることに注意してください。 そうしないと、デンバーはリンクを取得しません。



generate.pyスクリプトにはqooxdooディストリビューションへのパスもありますが、この場合、パスの相対性は重要ではありません-Pythonはスクリプトを絶対パスでもコンパイルします。



さらに、私が知る限り、ソースバージョンは外部ライブラリでは機能しません。 少なくとも、Open Flash Chartの外部インターフェイスであるジョブを介して接続しようとすると、ソースは機能しませんが、ビルドは正常に機能しました。 外部接続は、アプリケーション内にインターフェイスクラスを導入することで置き換える必要がありました。



UPD ：サーバーから起動されたソースバージョンは、影響を受けるjs_fileクラスのすべてを個別に取得します。 ウィンドウでfirebugが有効になっていると、ブラウザが簡単にハングアップします。 起動中に「ネットワーク」パネルを無効にするのに役立ちます。