Chura用Pluginの話。

設計

本日は、壮大なるペーパーウェアベーパーウェアの話です。*1


現時点では、大きく分けて、３つのグループの機能を作る予定です。
ひがさんと、思想や歩調が完全に合っている訳では無いとは思いますが、
大体同じ方向を向いているつもりです。


一応、僕が実装する予定の順番に機能が並んでいます。
よって、同じ分類に入る筈なのに、バラバラの位置にあり、
若干読み辛い事もあるかもしれませんが、ご容赦下さい。

TeedaExtensionの補完機能

  • html と Page クラスをQuickJUnitの様に、フォーカス遷移出来る様にする。
    • ショートカットキーで移動出来て、かつカスタマイズ出来る。
  • html から Page クラスを自動生成する。
    • htmlに含まれるid属性のうち、予約語を除く、すべてのid属性を、Pageクラスのメンバとする。
    • htmlに含まれるid属性のprefixが、doもしくは、goの場合、ナビゲーションアノテーションを自動生成する。
    • ナビゲーションアノテーションは、後からでも、単独で追加する操作が可能。
  • html に変更があった場合、変更差分をPageクラスに取り込む。Generate Getter and Setterの様に振舞う。
    • コンテキストメニューは、.html及び、.javaでメニューが出力される。
    • 変更差分がある時、.htmlにワーニングが出力される。
    • 変更差分を取り込むプロパティの出力先を、HTMLと対応するPageクラス、もしくは、その親クラスから選択出来る。
  • 自動生成されるPageクラスの数は、設定可能。
    • Pageクラス(DTO) + Actionクラス
    • Pageクラス(DTO + 振る舞い)
  • Title、Metaタグに対応するアクセサを自動生成する。
    • コンテキストメニューから、getTitle,setTitleを自動生成できる。
    • Metaタグのhttp-equiv属性を、DTOのプロパティ名として採用し、アクセサを自動生成できる。

KuinaDaoの補完機能

  • Entity、Dao、及び、EntityLogicを自動生成する。
    • 元になるデータが、Excelなのか、DatabaseMetaDataなのか、EMFなのかは悩ましい所。
    • Daoは、通常使用すると思われるメソッドを固定で生成する。*2
    • EntityLogicは、Daoに処理を丸投げするメソッドを生成する。
  • Dao用テストコード及び、テストデータの自動生成
    • Daoに自動生成される程度のメソッドに対応するテストのコードは、自動生成してしまいましょうって事です。
  • JPQLの対話的な実行環境
    • SQLは対話的な実行環境がそれなりにありますが、JPQLは今の所余り無いので…。
  • Entityクラスのプルダウンメニューから、各種マッピングを追加する。
    • 「N:1」、「1:N」、「N:M」マッピングの追加。
    • 不可逆であり、メタ情報がコードにしか、残らず、一覧性が低いのが、賛否両論ありそうですが…。
    • 中間モデルとして、EMFやら、Excelやら扱うのも、それはそれでどーなの？…と。


極端な話、僕が、JSFに対する理解よりも、
相対的にJPAに対する理解が足りていないので、製造のプロセスが見えていません。
つまり、機能の必要性や、仕組みの複雑さを軽減する為のツールの適切な位置づけが見えないのです。


僕の個人的な意見ですが、
O/Rマッパーとは言っても、RがRelationalでは無く、ResultSetで何が悪いのか
未だに明確な答えを持っていません。
まぁ、少なくとも僕はOO原理主義者ではナイノデ。

その他の機能

  • AutoRegistorのサブシステムをGridで登録できる。
    • これは、まぁ、diconファイルを直接編集しなくても良い様にする事のやり始めって感じです。
    • AutoRegistorによって、殆どdiconファイルを記述しなくても良い様になっていますが、
      実質的には、未だ幾つかのdiconファイルは、手で編集しなければなりません。
      既に慣れてしまっている人にとっては、特に難しい事では無い*3のですが、
      そうでない人もいるでしょう…と言う感じの機能です。
    • 新しくサブシステムを登録したら、そのパッケージ名以下に固定のパッケージが、ごっそり生成されると良いかも…。
  • Churaプロジェクトウィザード
    • ルートパッケージと、サブシステムパッケージを設定すると、固定のパッケージが自動生成される。
    • Churaを動かす為のライブラリに対する参照が自動設定される。
    • TeedaExtensionでは、ある程度パッケージ構成が固定される部分があります。
      一つ一つ操作して作るのもまぁ悪くは無いのですが、あったら便利でしょう…と言う事です。
  • 使用しているSeasar2のライブラリと、リリース済みライブラリの間に、差分がある場合、
    Wizard経由でjarファイルを、seasar.orgから取り込み、.classpath等を変更する。
    • この機能は、別なプラグインとして独立してても良いかなぁ…とは思います。
      eclipseのsite.xml+α的なものをサーバにおくと、ライブラリを自動的にバージョンアップしてくれるという機能です。
      S2は現在でもBugFixや機能追加がそれなりのスピード感を持って行われているのですが、全てのユーザにMLやSVNを追いかけろと言うのは、
      無理な相談ですが、自動的に通知されれば、少しは関心を持って貰えるかな…と。
      リアルタイムに問題が起こっているユーザは、リビジョンをあげるだけで解決するケースもそれなりに多いんじゃないかなぁ…と思います。
    • イメージ的には、WindowsUpdateのJavaプロジェクト用eclipseプラグイン版。みたいな。
    • そもそも突き詰めていけば、maven的ネーミングルールのjarファイルがあれば、
      そこからテキトーなMaven Repositoryから最新のJarファイルを持ってくる事が出来るんじゃネーカナー…とか、そういう機能です。
      只、リリースノートとセットで確認する事が出来ないと、ちょっと危なっかし過ぎるなぁ…とか。

最後に、有難くも無い、基本的な思想の話

僕が作るプラグインは、ツールを三本目の手と考えます。
つまり、一回の操作では、ほんの少しの事しかしません。
そもそもS2回りのライブラリは、ツールなんか無くても快適に開発出来るレベルにある事が多いと思います。
それでも、尚、繰り返しやらざるを得ない単純作業は存在します。
その単純作業を、ツールが肩代わりします。
なので、一回の操作で、見渡せない程大量にリソースが出来る事の無い様に考えています。


自動生成系のツールは、生成されるマテリアルの量が増え過ぎる事で、
システムの複雑さを隠蔽する所か、増大させる危険性を持っています。
自動生成された部分をちょっと変えただけで、
見た事も無いエラーが、ごっそり出力されて、
何が起きているのかサッパリ分らないけど、上手く動いてない事だけは分った。
みたいな笑えない状態には、なるべくならない様にしたいのです。


結局の所、これから僕が作り込むプラグインでは、
慣れていれば、手でやっても5分か10分で出来る事を、
コンテキストメニューから選ぶだけで…つまり、数秒程度で出来る様にする事が、
重要だと考えます。
つまり、ツールが機能を提供した部分に関しては、慣れていようが、慣れていまいが、
数秒で作業を完了出来る事になります。
これによって、プログラマが単純作業に充てる時間を減らし、より複雑な問題を解決する為に、時間を使う事が出来る様になれば良いなぁ…と。

*1:防御線

*2:INSERT,DELETE,プライマリキー検索……

*3:少なくとも僕は、diconファイルの編集に苦を感じません。