Mayaaソースコードの読み方

Mayaaのソースコードの読み方

MayaaのソースコードはGitHubにあります。

さて、git cloneで落としましたか？

今日はこいつの読み方を説明します。準備は良いでしょうか？

プロジェクト構成を眺める

プロジェクトフォルダをざっと見ると、

src-api
src-impl

2つのフォルダがあります。僕はこのようなフォルダ構成はMayaaしか知りません。試しにGoogleで「src-impl」と打ち込むと、Mayaaのソースが出てくるからMayaaの独特の構成かもしれません。

contect フォルダはライセンス情報や依存ライブラリ、Webアプリとして単体起動させるための設定情報などがあるだけで、ライブラリとしてあまり重要なものはありませんので、コードリーディング時は無視してよいです。

src-apiでAPI構成を知る

src-apiにはinterfaceが定義されています。つまり、src-apiに存在するインターフェースは何らかの方法で実装を交換可能になっているということです。

実装が交換可能ということは、独立した部品とみなされていると言って良いです。つまり、src-apiをざっと見れば、Mayaaがどんな部品によって構成されているかを知ることが出来ます。

パッケージ階層を見ると次のような構成であることが分かります。

builder
cycle
engine
provider
source

Mayaa内部の用語なので、これだけ見ても、最初は慣れないと思いますが、そこで、Mayaaの処理する流れをざっと説明します。

engineはMayaa中心で起点と考えてよいです。

engineの中は、processorと、specificationに分かれます。specificationはmayaaファイルやテンプレートの定義情報をモデル化したものです。processorは、テンプレートエンジンがそのノードをどのように処理するかをオブジェクト化したものです。つまり、specificationによって組み立てられたprocessorがあればMayaaエンジンはHTMLを出力することが出来ます。

providerはアプリケーションスコープのリソースです。エンジンの設定や、各インターフェースの実装クラスの選択はここが担当します。そのため、Mayaaの設定はorg.seasar.mayaa.provider.ServiceProviderなのです。

sourceは、mayaaファイルやhtmlテンプレートなどユーザーが作成するソースファイルを抽象化しています。他のインターフェースに依存しませんが、実装上は、ビルド時にほぼ必ず使用します。

cycleは、リクエスト処理のコンテキストを扱います。リクエスト・レスポンス、現在処理中のノードといったスレッドローカルなコンテキストはここに格納されていきます。

builderは（主にsourceを元にして）SpecificationNodeを組み立てます。

つまり、provider, cycleは事実上Engineを動かすのに必要ですが、何らかの方法でspecification/processorが構成できてしまえば、builder, sourceは切り離せるとも言えます。

継承の起点としてのインターフェースを理解する

次に、クラス階層から実装の作法を理解してみましょう。

こんなクラスが実装の起点に存在しています。

PositionAware
- NodeTreeWalker
- ParameterAware
ContextAware
UnifiedFactory

これらをざっと眺めておくと後々実装を追いやすくなります。

実装クラスの起点はMayaaServletから

なんだかんだ言っても実装はMayaaServletから追い始めるのがベターです。

MayaaServlet#doServiceで、Cycleを初期化し、ProviderからEngineを取得して実行しているのが分かります。

EngineImpl#doServiceを追って行くと、EngineImpl#doPageServiceという大きなメソッドに行き着きます。ここが、一リクエスト分のレンダリング処理の主要部分です。ここを起点に、テンプレートの情報を取得し、各部品を実行することで、結果としてのHTML文書が出力しされます。

大枠を理解できたら後は部品ごとの設計を理解する

例えば、SourceDescriptorは内部でCompositeパターンになっています。Processorを理解するには、TemplateProcessorSupportという巨大なクラスの機能を理解する必要があるでしょう。

また、Rhinoスクリプティング機能は、cycle.script.rhino内に収められています。したがって、これと同等の部品を実装して、独自のCompiledScriptが実装ができれば、スクリプトエンジンをRhino以外に切り替えることもできます。

まとめ

Mayaaのソースコードは、各部品の独立性と抽象度が高く設計されています。このため、全体を各部品に切り離して考えることが出来、一部分を拡張したり、変更することが行いやすくなっています。

FactoryFactoryがある時点で、DIコンテナが普及する以前の香りがしますね。Seasarプロジェクトと言いながらSeasarに依存しないのは、このように独自にフレームワークを作っているからなのです！また、今回は触れませんでしたが、内部には、GCの管理や、シリアライザーをガリガリいじったり、相当低レベルのこともしています。（それらを読んでいるととても勉強になります）

こういった低レベルな部分がソースを膨らませているとも言えます。何も知らないで読むと、溺れてしまいそうです。しかし、フレームワーク的なところ、低レベル過ぎるところは一旦置いておくと、読むべき範囲は限定されてきます。

ソースコードを読む動機というのは様々で、拡張したい時の他に、トラブルシューティングをするとき、パフォーマンスチューニングしたい時などいろいろあると思いますが、その時必要な範囲で読めるように、普段から慣れておけば、そんなに怖いものではありません。

Mayaaの学び方・教え方

もし、プログラマー初案件がMayaaだったら

今日のテーマは教育です。プログラミングは学校で習った程度で、Servletとか作るのは初めてな感じの新卒が、Mayaaを使っているチームに配属されたとします。

経験者なら良いんです。
Mayaaの公式ドキュメントを読んでください。その後、僕のブログで、このアドベントカレンダーの1日目から7日目を読んでくれれば良いんです。

JSP、Thymeleaf、JSF、Mixer2を経験しているなら、17日目から21日目も読んでおくと理解の助けになるでしょう。

後の記事はアーキテクトやリーダープログラマー向けなので、ぶっちゃけ読まなくてもいいです。（笑）

さて、本当にど初心者が入ってしまったらどうでしょうか？「JSPでは〜」というのが言えなくなります。

とりあえず、JSPを理解してもらう。

最近はフレームワークでドーンと最初から統合されたシステム作りをするのが主流だと思いますが、MayaaはJSPと同じレイヤーにするために、そのものはシンプルでもないのですが、JSPを覚えておく必要はあります。

昔だったらStrutsを使ってMVCにしても良かったのですが、今はSpringとかJava EEのような重量級をいきなり使うのはきついので、いっそ、生のServletとJSPでページを構成する体験をしてもらうしかないのかなと思います。

いしがみメソッドの4種類それぞれを実装してもらう

Mayaaそのものは柔軟性のある技術ですが、実際のプロジェクトでは、デザイナーと協調するために、いしがみメソッドでは、4種類の書き方に限定することを提唱していました。

しっかりと、4種類だけに限定して書く癖をつけてもらいましょう。

3日目から引用すると、

*_HERE
- その場所に文字列を出力する
*_TAG
- そのタグの属性を変化させたり要素を足したりする
IF_*
- そのタグ及びその子要素が特定の条件にもとづいて消える
LOOP_*
- そのタグ及びその子要素を特定の条件に基づいて繰り返す

そして、それぞれの書き方は

<!-- タイトルを出力します -->
<m:write m:id="TITLE_HERE" value="${page.getTitle()}" />

<!-- 商品画像を表示します。src属性を制御します -->
<m:echo m:id="ITEM_IMAGE_TAG">
  <m:attribute name="src" value="${image.getSrc()}" />
</m:echo>

```markup
<m:if m:id="IF_MEMBER" test=${context.isMember()}>
  <m:echo><m:doBody /></m:echo>
</m:if>


```markup
<m:forEach m:id="LOOP_ITEM" items=${items}>
  <m:echo><m:doBody /></m:echo>
</m:if>

きちんとレビューをしてこの通りに書いていなかったら直させるようにしましょう。

これらを書くことは業務の中で圧倒的に多いことです。

まとめ

使い方を絞ったことによって、教える時も絞って教えられるメリットがあります。

ただ、教え方は人それぞれ、教わる方も、それぞれ向いたやり方は違いますので、「これがベストだ」とは言いづらいところがあります。

なので、今回は歯切れが悪くなってしまいますが、まあ、適宜、教育する人、教わる人で、良く話して、ベストなやり方を模索してください。

Mayaaの生まれた日から現在までのWebのフロント開発における時代背景の変化を振り返る

Mayaaの歴史とWebの歴史

今日は、そもそものMayaaの存在意義を過去から未来に向けて探るため、Mayaaが生まれた時代背景を振り返ってみたいと思います。

Mayaaが誕生した時期のWebの状況

Mayaaは2005年のIPA未踏ソフトウェア創造事業に採択されています
公式ドキュメントによると

Mayaaは、すでに2004年11月より、開発がスタートしています。事業に応募した2005年3月現在でも、一通りのコンセプトを実装したプロトタイプ製品がリリース直前の状態ではありました。

とあるので、コンセプト部分は2004年～2005年に生まれたことになります。

当時の言語・ライブラリ・フレームワーク・ミドルウェア・ソフトウェアの最新版はこんな感じです

名前	バージョン
J2SE	5.0
J2EE	1.4
Tomcat	5.5.x
Struts	1.2.x
IE	6 SP2
Firefox	1.0
PHP	5.0.0
Ruby	1.8.2
Ruby on Rails	1.0より前のバージョン

Googleマップのリリースとともに、「Ajax」という単語が生まれたのがちょうどその時（2005年2月）で、まだPrototype.jsやjQueryとかはありません。

WebレイアウトはCSS2はありますが、まだtableレイアウトも使われていた時期です。

そんな時期から、デザイナーとプログラマーの分業の需要があったのはちょっと驚きです。

Web2.0という言葉が出てきたのもこの時期です。

僕がMayaaを使い始めた時のWebの状況

僕が初めて触ったのは2009年8月です。その直前にWicketブームなんてのがあり、Webの開発スタイルがStrutsから大きくシフトしようとしていた時期でもあります。

当時は既にjQueryも存在し、Ajaxも一般的に使われ始めていました。モダンブラウザも生まれていましたが、IE6対応が必須の時代でした。HTML5は草案が出たばかりで、これからという感じでした。

iPhoneは3GS、AndroidはHT-03Aが発売したばかりでした。

Mayaa自体は既に成熟期に入っており、大きな変更はありませんでした。

つまり、Web2.0期の発祥とともに開発が始まり、モバイル時代に入る前に成熟期に入っていたMayaaを僕は使い始めたのでした。

運が良かったと思います。劇的な変更がほとんどなかったので、開発中のシステムをMayaaの最新バージョンに追従していくことが容易でした。

スマートフォン対応・HTML5の時に、nekoHTMLパーサーをビルドしなおさなければならなかったことはありますが、Mayaaは設計が良いのか、現在まで大きな問題なく使えています。

なお、ThymeleafやMixer2はこの後登場します。

現在のWebの状況

2013年くらいに、Webのフロントの世界に激震があり、Angular.jsなど、SPAの技術が旧発展します。

node.jsの発展ともにnpmなどのエコシステムも充実し始め、Grunt / Yeoman / Bower などもあって非常にキラキラしたフロントエンド時代が到来していました。

こうなってくると、サーバーサイドの仕事は、減ってきます。極端な話JSONを返せば良いこともあります！

ただ、SEOが必要な場合、SPAにすることは出来ませんので、サーバーサイドがHTMLを生成する需要は未だにあります。しかし、それで吐き出されたページはBootstrapが入っていたり、だいぶキラキラしていて、そこから先にAjaxを平然と行ったりします。

そして、今年、Mayaaの参加する、Seasarプロジェクトが来年で終了することがアナウンスされました。（Mayaaは今後もメンテナンスを続けます）

未来の予想

Webは混沌としていると言われます。でも、それは、需要がますます高まり、多くのプレイヤーが入り乱れているということも意味しています。

SEO全盛が終わり、IoTやオムニチャネルの時代になってくると、サーバーサイドテンプレートエンジンの技術は必要性が薄れて行くでしょう。

テンプレートというUIよりも、UXの設計が重要と言われますが、ますます顕著になるでしょう。

あと、1,2年で劇的に変わるかもしれません。

その時、Mayaaは役目を終えるのでしょうか？Mayaaが生まれて既に10年を過ぎますが、ニーズがある限りメンテナンスは続けられます。

まとめ

MayaaはいわゆるWeb2.0期に誕生し、Web全盛時代を生き抜きました！今でも十分問題なく使えます！この時代、人々はPCやスマートフォンのブラウザを使って、コミュニケーションをしてきました。

Mayaaがここまで生きてこられたのは、デザイナーが自由にデザインを作ることを制約しない設計であったことがポイントだったと思います。

僕は、IoTや人工知能の時代になっても、これまで紙だったものがWebに置き換わる需要の方が多いと思っているので、すぐに衰退はしないと思っています。そして、Mayaaが使われている限り、メンテナンスに参加し、情報を発信して行きますので、今後共よろしくお願い致します。

susumuis Info

Webエンジニア susumuis の技術ブログ