intra-mart Accel Platfom 上でKotlin(じゃなくてもいいけど)でアプリ書きたい
GWをつぶしてあれこれ考えてみたけど結局ダメそう、と言う時間の無駄をシェアさせていただきます。
- intra-mart Accel Platform 上で開発するアプリケーションには開発言語として Java(フレームワークいろいろ)とJavascript(JavaScript Server Pages : JSSPと言われている)が使えるんだけど、そろそろScalaとかClojureとかKotlinとか使えたほうがいいんじゃないの、と思ったりしてみた。まあ個人がいろいろ考えても本家のほうでサポートしてくれなきゃ意味ないんだけど。
- とりあえずユーザーの乗り換え障壁が少なそうなKotlinを考える
- Javaとのインターオペラビリティはそれなりに高そうだから、JSを実行している実行エンジンの部分で同様に切り替えるような仕組みを作ればいいんじゃないのかな
- とりあえずそれができそうなインタフェースとして公開されているのは BaseAuthzUserAction (公開されてない)あたりかなあ。
- とはいえ、KotlinでJavaのアノテーションがそのまま使えるのであれば、WEB API MakerでWeb APIを作るのであれば問題なくやれるんじゃないのか。
- ということで開発環境にKotlinの適用を考える。
- Accel Platform の 開発環境といえば e-Builder。
- e-Builderといえばeclipse。
- Kotlinのeclipseプラグインてあるのか?
- 公式サイトに一応リンク載ってる
- インストールして試してみるが、サジェスト以外のサポートは受けられない模様
- 外部のクラス参照しようとしても(サジェストされるのに)自動的にimportを書いたりはしてくれない
- たぶんリファクタリング操作もそんなに期待できないのでは・・・。
- やはり IntelliJ IDEA でなければならんのか?
- Kotlinのeclipseプラグインてあるのか?
- IntelliJ IDEA の Ultimate には最初からResinプラグインが入っているから、IDEからResinをコントロールするのはそれほど問題がない。(別にResinじゃなくてもいいんだけどまあ一応)
- IntelliJ IDEA はビルドの処理をあれこれ設定ベースでコントロールできるので、im-Juggling で作ったwarを元に、そのソースを展開して、Kotlinで書いたコードを混ぜこんでJava EE 形式のWebアプリケーションとしてResinに実行させるというようなことはいろいろ設定を頑張ればできなくはない。
- 正直、いちいち手で設定するのはかなり面倒。この辺初期セットアップをプラグインなんかで補助できればいいんではないかと思っているけどその辺はよく知らないのでとりあえずパス
- デバッグ実行にしておけばKotlinのコードをコンパイルしたタイミングでクラスはホットスワップされるっぽい
- なんか挙動が妙(たまにResinが丸ごと再起動する)な気がしているのだがあまり深く検証していない
- まあそんなこんなでもとりあえずWEB-API makerの手順にあるような構造のコードをアノテーションばりばり書きつつKotlinで書いてみて、Swaggerから呼び出したりホットスワップで挙動が修正されるのは確認できた
- まあクラスファイルにコンパイルされるのは同じなわけだから当たり前なのか
- しかしそれでWeb-API書けたとして、クライアントどうやって書くんだ?
- 素のHTMLだとテーマとかメニューとか認証認可とかなんだかんだいろいろ抜け落ちるわけで、なんかRouterを介したエントリーポイントとなるViewを吐き出す必要がある。
- ここもKotlinでやろうとすると上記の通りBaseAuthzUserAction とか要するにRouter周辺の拡張を書かなきゃならない
- だったら最初からそっちに取り掛かったほうが良かったじゃん
- JSSPで書いてもいいんだけどなんかそれも負けた感じ
- ここもKotlinでやろうとすると上記の通りBaseAuthzUserAction とか要するにRouter周辺の拡張を書かなきゃならない
- それはそれとしてもクライアントサイドはやはり今はやりのJSフレームワークとかAlt JS的なツールチェインを使いたいけど
- Java EE的なビルドプロセスの中でNodeJSのツールチェイン混ぜこむのどうしたらいいわけ
- mavenからnode.js実行したりnode.jsからmaven実行したりgradleからnode実行したりいろいろあるようだ。が、どれもあまりスマートには見えない。まあ追加でNode.jsを要求する時点ですでにいろいろ難しいのだが。
- クライアントサイドとWeb-APIで別なプロジェクトにしてしまえばあるいは
- プロジェクト構成もどうするのがいいのか悩ましい。e-Builderが用意するデフォルトのpublicディレクトリには直接ソースをおかず、別なディレクトリでTypeScriptとかES2015とかで書いたものをコンパイルしてpublicにもっていけばいいのか?
- その場合そのコンパイルを行うwebpackとかbrowserifyとかの基準ディレクトリはどこに置いたらいいのか?個人的にはプロジェクトルートに置きたい感じがすごいする(npmをプロジェクトルートディレクトリで実行すればいいから)けど、そうしてしまうとそれはそれでルートにいろいろできてうざい気はする
- それに普通にpublicに置きたいリソースがあった場合(imgとか)どうなるのか。
- ていうかwebpack初めて触ったけど設定の書き方がものすごく不安。いろいろ書きすぎなんじゃないの
- また半年とかしたらオワコンとか言われたりするのかしら
- 忘れもしない2013年前半、これからはAngular!Angular!みたいなことをあちこちで言いまわっていたくせに俺がAngularつかったシステムリリースしたとたん手のひら返したようにオワコンオワコン言いだしやがったフロントエンド界隈の連中絶対に許さんからな
- また半年とかしたらオワコンとか言われたりするのかしら
- こういうpolyglotというか複数のエコシステムが絡み合う問題は少し前から気になってはいたけど、なんかうまくやる方法あるんだろうか
- Java EE的なビルドプロセスの中でNodeJSのツールチェイン混ぜこむのどうしたらいいわけ
というわけで、まあクライアントサイドのビルド関係の話を除くなら開発環境のサポート具合と結局Routingで各言語対応しなきゃならなさそう、というあたりがとりあえずの障壁?
KotlinでServlet書いてもいいけど、それだと認可のためにrouting-servlet-configを書く必要があるな。今は亡き?SAStrutsサポートとかTERASOLUNAフレームワークサポートでやってるような方式がこっちにも応用できるようならそのほうがいいだろうけど。どうなんだろ。