@Java, Ymir Ymir-1.0.2がリリースされました。 Ymirのトップページ あまりこのBlogではWEBフレームワークの話題をしませんが、 ちょっと今回ばかりはWEB側に寄ってみましょう。
このYmirというフレームワークを「個人的な非公式な見解で」 大きく５つの特徴を挙げて紹介します。 A. HTMLテンプレート(+ 自由度高い) B. PRGパターン(+ Forwardもできる) C. スコープ管理(+ 自由度高い) D. Pageクラスの自動生成(+ GenerationGap) E. HotDeploy(+ 自動生成結果も即反映) 「A」と「B」と「C」は、先進的なフレームワークであれば、 サポートされていることが多いですが、Ymirのポイントは、 「いざってときの小回りが利く」 というところです。これらの機能をサポートした場合に一般に 問題になるのは自由度です。いざってときどうするの？ (規約にハマらないイレギュラーケースなど) というのが、とてもとても現場で問題になるのです。 「HTMLテンプレートはGoodだけど複雑な画面はどうしよう...」 「PRGパターンはGoodだけど携帯アプリはどうしよう...」 「スコープ管理はGoodだけど構造とフィットしなかったらどうしよう...」 かといって、これらの機能はいまや捨てられません。 実際に開発を経験した感じ、とてもとてもメリットを感じました。 特にHTMLテンプレートは(実務的に)本当に素晴らしい。 S2Daoの2WaySQLを見たときと同じような感動ですね。 ただ素敵な機能には現場にフィットさせるための調整が必要です。 Ymirの「A」と「B」と「C」はその調整が見事にされている感じです。 nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn A. HTMLテンプレート(+ 自由度高い) nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn HTMLテンプレートのメリットは言うまでもありません。 ここでポイントにしたいのは、ZPTを利用することで 非常に小回りが利くということです。 感覚的に一言で表すと、「マニュアル車」な感じです。 ちょっと記述が面倒に思うこともあるかもしれませんが、 HTMLはとてもセンシティブな領域なので実はその方が良いのです。 色々経験してないとなかなかわからないメリットではありますが、 コンシューマ向けアプリでデザインマージやらなんやらで HTMLをたくさん調整する経験をしたことのある人なら 「これだー」とわかってもらえるかと。 (いきなり地味な主張になってしまったかな！？) nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn B. PRGパターン(+ Forwardもできる) nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn PRGパターンが主体でもいざとなればForwardできます。 PC上WEBアプリと一緒に携帯WEBアプリも作った人なら 「これだー」とわかってもらえるかと。 nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn C. スコープ管理(+ 自由度高い) nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 基本はパッケージ構造をベースで、いざとなればそれに依存せずに どういう形でもスコープを定義できる形式がGood！ 「Conversation」という名前の機能です。 「どの画面とどの画面が一つの業務的な固まりなのか」を 細かく制御ができ、その定義したスコープを基準に値を持ち回したり、 不正な画面遷移のチェックをしたりすることが可能です。 感覚的に一言で表すと、「マニュアル車」な感じです。 ネストしたスコープ管理も可能です。 ネストしたトランザクションを想像して下さい。 トランザクションを一旦サスペンドして新たなトランザクションを 発行して、その内側のトランザクションが終わったら外側の トランザクションを再開させる、というような感じ。 (ああごめんなさい、やはりDB側の話をどうしてもしたくって) このような制御を画面でのスコープ管理でも可能なのです。 実はこれがないと実務においては結構大変で、スコープ管理の サポートされているフレームワークを実際に使ったとき、 このネストスコープの概念がなかったため、結局自前で 値を持ち回す機構をその場で作る必要がありました。 (しかも全然違う二つのプロジェクトで同じように) 敷居は多少高いのですが、敷居が低くて開発終盤で苦しむより、 敷居は高いけどしっかり管理ができて小回りが利いて開発終盤で 特に困らない方が良いと考えます。 nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn D. Pageクラスの自動生成(+ GenerationGap) nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn Pageクラスはもちろん自動生成ですが、GenerationGapです。 一度生成した後も何度でも再生成可能です。プロパティ追加や ボタン追加時もとっても楽です。(実感としてとてもGoodでした) HTMLの部分に比べ、堅いJavaの世界に関しては、 逆に徹底して「オートマ車」な感じです。 しかも自動生成はPageクラスだけじゃありません。 DTOクラスもそうですが、Dxo相当のConverterも自動生成します。 詰め替え処理はリフレクションじゃないので、とても安心です。 プロパティ名やアクション名の定義がPageクラスに自動生成されます。 これを使うことによって、Pageクラス上でのプロパティ名の指定や アクション名の指定など、ほとんどタイプセーフになります。 HTMLを修正して再自動生成したら、古いPageクラスの記述は コンパイルエラーで検知可能です。なんかDBFluteっぽいですよね。 ちなみにこの自動生成のタイミングがとても特徴的です。 アプリケーション起動中に必要に応じて自動生成します。 ブラウザ上で自動生成画面が表示されてOK押すと自動生成ってな感じ。 裏でバッチファイルを叩いてどうのこうじゃないんですね。 その自動生成した内容がそのまま反映されて次のリクエストで動作します。 「E」の機能が関連することによってそれが実現されています。なので、 Tomcatを落とすこと無くどんどん自動生成しながら開発が進んでいきます。 nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn E. HotDeploy(+ 自動生成結果も即反映) nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 「D」の説明で既に登場なので省略します。 これはYmirの機能というよりコンテナの機能ですが、 Ymirはそれを最大限に活かして開発できます。
Ymirの開発スタイル(フロー)は以下のような感じになります。 1. HTMLを作成(外部設計時など) 2. HTMLをZPT化 3. アプリを起動してブラウザから該当HTMLへアクセス 4. ブラウザ上で該当Pageクラスを自動生成 5. Pageクラスに処理を書いて実行して動作確認 (x. 変更があった場合はHTMLを直して再自動生成) わかってしまえば、かない良いリズムで開発することができます。 が、とても「立体的な」開発スタイルであるため、 ちょっと実際に作ってる様を見てみないとなかなか 伝わりにくいかもしれません。そういった動きのある ドキュメントを作っていくのが課題の一つかなぁと思います。
「Vili」というYmirを支援するEclipseプラグインがあります。 こちら、以下のような機能を備えています。 o Ymirの(Eclipse)プロジェクトを生成する o PageクラスとHTMLを行き来する(ctrl + 5) o 該当PageクラスとHTMLのリクエストを飛ばす(View On Server) o DBFluteのバッチファイルを実行する WEBアプリ開発で必要な基本的な機能は揃っています。 今後ももっともっと便利になっていくことでしょう。 あれ！？なんか一つ変なの混じってない？ 「DBFluteのバッチファイルを実行する」 そうなんです。 実は、既にEMechaで出来てないことが先に実現されています。 右クリックメニューからDBFluteのGenerateやSql2Entityが 実行できて、ログがコンソールに出力されるようになっています。 この機能は、Ymirを使っている使っていないに関わらず利用可能に なっています。(本当にありがとうございます) ぜひDBFluteユーザの方は使ってみてください。 Vili自体は「SeasarのEclipse更新サイト」にあります。 「http://eclipse.seasar.org/updates/3.3/」 1. インストール(一般的なプラグインのインストールと同じやり方) 2. DBFluteが設置されているプロジェクトのプロパティを開く 3. 「Vili」という項目で「Viliプロジェクト」にチェックしてOK 4. 右クリックして「Vili」で「フラグメントを追加・更新」 5. フラグメントで「DBFlute」にチェックを付けてOK 6. 右クリックして「Vili」で「アクション」で... (後は実際に試してみた人のお楽しみ) まあ、タスクをEclipseから直接実行で 慣れている人はそれはそれでいいかなとってところですが、 いつもエクスプローラで辿ってダブルクリックしてる人には 試してみる価値はあるかと思います。 ログがコンソールに出るっていうのがとても良いです。 Windowsのコマンドプロンプトだとちゃんと設定しないと ログがとても見づらいので、Eclipseのコンソールに出力される ってのはとても価値があります。 # # ちなみにdbflute-basic-exampleには、既にViliのこの設定が # されているので、Viliを入れたらいきなり右クリックで実行できるんじゃ # ないかと。。。(もしかしたら4と5は必要かも...) #
課題はまだまだあるかと思います。 ZPTの支援エディタ(Eclipseのプラグイン!?)がまだありません。 マニュアル車っぽい分、そういう支援があった方が良いですね。 実装ポリシーの確定も大事です。細かいレベルで複数の実現方法が ある場合に、どう実装するのが一番良いのかが迷うので、 正解はケースバイケースにしてもある程度の指標があった方が良いかと。 (まあExampleの充実ってところにつながりますね) また、先述していますが「動きのあるドキュメント」も必要です。 その他細かいところ色々あるのですが、解決不能な課題じゃなさそう なので、今後のバージョンで良くなっていけばよいかと思います。
YmirとDBFluteが連携するExampleを作りました。 プロジェクト名：dbflute-ymir-example 参考HTML(検索一覧画面)：list.html 参考Pageクラス(検索一覧画面)：ListPage.java ※直下のreadme.txtをお読み下さい。 プロジェクト構成としてMaven2に依存しておらず、DBは「H2」で 組み込みなので、チェックアウトしてTomcatに設定すればすぐに 画面を起動することができます。 かなり実践的なExampleとなっております。 実際の開発時にとても参考になるかと思います。 興味のある方は、ぜひ色々見てみて下さい。
書き切れないので、とりあえずこの辺でまとめますね。 総合的に感じたのは、 魅力的な機能に対して必ず「いざとなれば」機能が付与されていて、 「とても現場にフィットするように調整されている」 という点です。かつ、徹底してツールを活かして安全を演出しています。 バランスが整っている感じです。 一方で、魅力がなかなか伝わりにくいフレームワークであるかなとも 思っています。本記事で取りあげた「大きな特徴」は、実際に 別のフレームワークでWEBアプリを幾つもやって苦労してきた人 (かつ、プロジェクト全体の利益を考えられる人)じゃないと、 なかなか理解されないものです。 (現場指向フレームワークの宿命かもしれませんね) なので、ユーザからすると「面白そうだから使ってみる」ではなく、 「役に立ちそうだから使ってみる」が主なきっかけになるかと思います。 それだと一気に爆発的に人気が出るってことはなかなかないのですが、 「わかる人(現場な人)にはわかるフレームワーク」 ということで、ちょっとずつちょっとずつ広まっていくことを 期待したいと思います。(DBFluteが歩んできた道と同じですね) 個人的には、今、２０人月とか１００人月を超えるような規模で ０からのスクラッチ開発をするとなったら、Ymirを選択するでしょう。 (個人的な話ですが実際にその規模での案件での実績を知ってますし...) 夢見るゆみる - 1.0リリースでYmirアプリ開発がどう変わるか - ぜひ頑張って下さい。(自分も行きます)
