ExtJS の分かりやすい本が欲しい
ついにうちの部署でも ExtJS で Web アプリを開発することになった。
何年か前に購入したという ExtJS 4 の本 ( 今は ExtJS 6 が出ているので情報が古くなっている ) を見ながらえっちらおっちら触りはじめたのが、あまりの不便さに液晶モニタにストレートをぶち込みたくなることしばし。
うすうす気づいていたことだが ExtJS の開発しづらさは異常。
GUI パーツが簡単に利用できるのはいいのだが、デバッグしづれえ。
- 馴染みがあって、覚え易い
- 速く開発できて、簡単にデバッグできて、簡単にデプロイできる
- 整理されて、拡張も可能で、メンテナンスも可能
が、うたい文句じゃないんかい。
ExtJS で何がイヤかと言うと、機能追加でどんどん新しいファイルが増え、乱雑化してきたディレクトリを整理しようかって思ってファイルを移動させたり名前変更したりして、それに合わせていくつものソースコードを修正し、いざ動作確認してみると真っ白なページが表示され、原因をつきとめようと思って Firebug を見ると「304 Not Modified 11ms bootstrap.js (1943 行目)」って何一つ参考にならないエラーが出ていたりすることだ。
変更したファイル名や xtype 、パスで全ファイル grep 検索して、なるほどここかと思って書き換えてみてもエラーは直らない。時間ばかりが経過していく。とても不毛な時間だ。
1 時間もやるとあきらめもついて、 git で作業前の状態に戻してやり直した方が早いかなと思い始める。
一個ずつファイルを移動させて、その都度 grep かけてソースコードを修正し動作確認。このやり方であれば変更箇所はかなり限定されるのでエラー原因も特定しやすい。整理すべきファイル・ディレクトリは分かっているので 10 分で終わる。
なんなの。
会社の経費で購入された、萌えイラストが多用された ExtJS4 の本には 1 つのファイルだけをピンポイントでデバッグする方法が載っていた。
ct/test/app.html
ct/test/app.js
ct/test/view.html
ct/test/view.js
上記の js ファイルで、特定のファイル (クラス) を呼び出すことで、その機能に限定したデバッグを行える。
html ファイルにアクセスしてブラウザで表示されなければ、そこに何らかの問題があるということだ。
うん、数十、数百ものファイルに対していちいちこんなことをやってられないよね。だが、原因に心当たりがないならこの方法で総当たりするしかない。恐ろしい。
本当か？ こんな言語ってあり得るの？ 実は分かりやすい開発手法があるんじゃないの？
昔 PHP でエラーがでねえって寝言言ったことがあったけど、 php.ini やらエラーコードの出力をコードで指定してあげるとばっちり出てくるんだ。そういうのあるんじゃないの？
(周りに聞いてみた)
え、知らない？ そうですか。
まあ ExtJS は JavaScript のフレームワークで、 apache から見れば全部のファイル送れてるんだからクライアント側のエラーなんて知ったこっちゃないというのは分かる。だけど sencha コマンドあたりが見つけてくれるんじゃないの？
ExtJS は実はデバッグしづらい言語なのだろうか。 GUI が簡単に利用できるのはいいんだが、デバッグのしづらさで相殺されている気がする。
そして萌え本。お前はいったい誰を対象に書かれたものなんだ？
実践開発と銘打っているくせにちっとも実践的な内容じゃないぞ。
初心者が見て意味わからないのはしょうがないにしても、章立てがひどすぎて 燃 や し た く な る。
2 巻の終わりの頃にデバッグ方法が描かれている実践開発って何？ デバッグの手法が最初じゃね？ 同じく 2 巻の終わりにある MVC アプリケーションの概念も最初にやるべき内容だよね。CSS セレクタとかやってる場合じゃないと思うが。
その程度は分かっているというユーザを対象にしたものだよ、というなら内容がお粗末すぎる。私は英語が不自由だが、公式にかかれたスタートガイドとサンプルを 英文 で見た方がよっぽど直観的に理解できる。
ExtJS の機能をグラフィカルに紹介している本と考えるといいのかも。中級者以上のユーザが眺めて、「あ、こんな機能もあったんだ」と感心する内容が 10% くらいある、かもしれない。
自費で購入してたら燃やしてたな。いや、わりと真面目に。
そんなわけでこの本を開くのは切羽詰まってちょっとでも多くの情報を集めたくなった時だけで、たいていは Google 先生に教えてもらっているわけだが、出てくる日本語のページはこの萌え本の著者の会社だ。えーと日本の ExtJS エバンジェリストか何かですか？ ただで見させてもらっといて何だけど、結構分かりづらいのよね。講習に参加させるためにあえて分かりづらく書いたんじゃないかと勘繰りたくもなる。
しょうがないので本家やら stackoverflow のサイトなんかを英文で眺めてその場をしのいでいるが、 Step by Step で教えてくれる本やサイトはないものか。資格取らされる時ですら参考書を買い渋る私だが、 1 万くらいなら自腹切ってもいいと思えるほど基本的な知識を欲している。
基本だけでいい。応用は本家のサンプルページからパクってくればいいし。
ぼやいてばかりじゃしょうがないしとりあえずやってみるか。
ExtJS 6 の環境構築
ExtJS 4 のサポート期限に終わりが来るので ExtJS 6 に移行することにした。最近 ExtJS 4 を触り始めたばかりなのに、次期バージョンのことを考えなければならないとか。
実は ExtJS 4 のまま開発を続けて行ってもいいのだが、 ExtJS 6 の MVVM で分かりやすい感じで開発してみたくなった。この辺は私の会社はわりと融通が利く。
とりあえず開発環境を作るところをまとめてみる。
端末が重くなるのは嫌なので開発環境をサーバに用意した。クライアント側では Visual Studio Code でコード編集をして、サーバにアップロードして動作確認することが前提だ。
SenchaCmd のインストール
SenchaCmd は ExtJS の開発環境を構築するための必須コマンドだ。分からなくてもとにかく入れよう。開発環境側、つまり今回はサーバにインストールする。
※ インストーラが X を使っているので、一般ユーザで実行する必要がある
※ クライアントに Xming というアプリケーションをインストールしている必要がある。この辺の設定は割愛。
※ サーバには JAVA をインストールしておく必要がある。環境変数の JAVA_HOME の設定が大事だと思われ。 .bashrc にでも JAVA_HOME を書いておこう。
1. クライアントの Xming 起動
サーバに一般ユーザ hoge で接続する設定にして Xming を起動する。
Xming はサーバに SSH で接続して、 X プロトコルを X11 転送してくれる。
これによってクライアントでは X クライアントが起動し、設定した内容がサーバに送られる。
2. インストーラ起動
これはサーバでの作業。
https://www.sencha.com/products/extjs/cmd-download/ から Linux 用の 64 bit か 32bit 用のインストーラをダウンロードする。当然サーバに合わせたものを。
$ cd /usr/local/src/sencha $ wget http://cdn.sencha.com/cmd/6.1.3/no-jre/SenchaCmd-6.1.3-linux-amd64.sh.zip $ unzip SenchaCmd-6.1.3-linux-amd64.sh.zip $ ./SenchaCmd-6.1.3.42-linux-amd64.sh
クライアント側でインストーラが走るのでそのまま次々に進み、最終的に /usr/local/Sencha/Cmd/6.1.3.42 にインストールした。
ExtJS 本体のインストール
ExtJS には、ワークスペースとアプリケーションという概念がある。
ワークスペースには ExtJS ライブラリと、アプリケーションのソースコードなどが入っている。
ワークスペースの作成 → アプリケーション myApp1 の作成 → コード修正 → ブラウザで動作確認 … (繰り返し) … → OK ならビルド → ビルドしたソースを本番環境にアップロード
こんな感じで開発する。
以下のようなディレクトリ構造にした。
| ExtJS 6 のソースコードを置く場所 ※1 | /var/www/ext-6.0.1 |
|---|---|
| ワークスペース | /var/www/workspace |
| ExtJS のコア※2 | /var/www/workspace/ext |
| アプリケーションの場所 | /var/www/workspace/myApp1 |
※1 /var/lib/ext-6.0.1 や /usr/local/ext-6.0.1 あたりが妥当なのかもしれない
※2 本体から切り出された extjs のディレクトリ。ライブラリ。各アプリケーションが共通して使う
1. ExtJS 6 の配置
- ExtJS 本体は Trial 版ではなく GPL 版をダウンロードする。
- たぶんライセンスは必要。確か開発者ライセンスとか言ったか。ライセンス管理は会社がやってるから詳細は知らないが。
- ext-6.0.1-gpl.zip は ExtJS6 と GPL で検索
# cd /usr/local/src/sencha # unzip ext-6.0.1-gpl.zip # mv ext-6.0.1 /var/www/
2. ワークスペースの作成
# cd /var/www/ext-6.0.1 ※ 入らなくてもいいが # sencha -sdk /var/www/ext-6.0.1 generate workspace /var/www/workspace
3. アプリケーション myApp1 の作成
# sencha -sdk /var/www/ext-6.0.1 generate app -classic myApp1 /var/www/workspace/myApp1 ※ -classic オプション : Touch Pad 不要。 modern ディレクトリを作成しない
4. ビルド
# cd /var/www/workspace/myApp1 # sencha app build
※ 本来ビルドはアプリケーションが完成したときに実行するが、 sencha app watch で修正した内容を自動更新させたいので、最初にビルド用ディレクトリを作成しておく。
5. httpd.conf の設定
# vi /etc/httpd/conf.d/extjs.conf
- Alias /extjs "/var/www/workspace"
- <Directory "/var/www/workspace">
- Require all granted
- </Directory>
# systemctl reload httpd
これで http://192.168.100.1 (サーバのIPアドレス)/extjs/myApp1/ で動作確認できるようになった。
sencha app watch
ExtJS の sass のデータを変更し、アップロードしても、そのままブラウザを表示させただけでは何も変わらない。
sencha app build が必要となる。 watch は、アップロードされたファイルを監視し、自動的にビルドを実行してくれる。
ただし、一般ユーザ hoge でアップロードする関係上、 sencha app watch もまた同じユーザ hoge で動作させる必要がある。そうしないと自動更新されたファイルが root などの所有者になってしまい、一般ユーザのアップロードに支障がでるからだ。
1. 権限を一般ユーザにするファイル・ディレクトリ
# chown -R hoge /var/www/workspace/myApp1 # chown -R hoge /var/www/workspace/build/development/myApp1 # chown -R hoge /var/www/workspace/build/production/myApp1 # chown -R hoge /var/www/workspace/build/temp/development/myApp1 # chown -R hoge /var/www/workspace/build/temp/production/myApp1 # chmod 666 /usr/local/Sencha/Cmd/repo/pkgs/catalog.json
2. sencha app watch を実行
$ cd /var/www/workspace/myApp1 $ sencha app watch &
3. 利用方法
ふつうにアップロードして動作確認するだけ。
例えば scss ファイルをアップロードすると、勝手に自動更新されてコンソールにメッセージが流れる。しばらくすると終了し、 http://192.168.100.1/extjs/myApp1/ で更新されたデザインが表示される。
ビルド用 URL ではなくアプリケーション直下の URL で動作確認するところが勘違いしやすそうなところと言えるかもしれない。
ちなみにビルドした ExtJS は高速。
http://192.168.100.1/extjs/build/production/myApp1