Category Archives: Java

mayaaの向いてるサイト、向いていないサイト

Mayaaに向くサイト、向かないサイト

Mayaaは、結構クセの強いテンプレートエンジンです。当然、すべてのサイトに向くわけではありません。今日は向くサイト、向かないサイトと紹介します。

Mayaaに向かないサイト

小規模なサイト

Mayaaデザイナーとエンジニアのコラボレーションを推進するテンプレートエンジンですから、当然、デザイナーとエンジニアのどちらかがいない時は必要ありません。

プログラマーが一人でガンガン開発するときはJSPの方が手っ取り早いかもしれません。

業務アプリケーション（開発者がMayaaに慣れている場合を除く）

デザイン重視ではない業務アプリケーションの場合も、Mayaaを使うメリットが活かせません。

Javaなら、JSFを使うか、いっそSPAにしてしまっても良いかもしれません。

ただ、開発者がMayaaに慣れているなら、その限りでもありません。いしがみメソッドでMayaaを使うことで、テンプレートが比較的スパゲッティにならず書けます。

折衷案として、いしがみメソッドを意識しながら、JSPやThymeleafを使うという手もあります。

高パフォーマンスが要求されるサイト

はっきり言って、Mayaaはそんなに高速なテンプレートエンジンではありません。内部的にかなり頑張っていますが、XMLをパースする、JavaScriptをコンパイルするという大仕事をしているためどうしても不利になります。

とはいえ、とんでもなく遅いわけでもありませんが、極限までのハイパフォーマンスが要求されるなら、あえてMayaaを選択する必要はないでしょう。

Mayaaが向くサイト

ECサイト

SEOが重要なECサイトでは、まだSPAを使うわけには行きません。ちゃんと静的なHTMLページを構成して上げる必要があり、metaタグなども結構細かく制御する必要があるでしょう。

また、ECサイトはフロントのデザイン変更が結構頻繁に必要になります。

そこで、運営者にある程度のマニュアルを渡して、サイト運営者と、運営者側のデザイナーのみでフロントをある程度いじれるようにできたら最高です。

ただ、そのためにはかなりのお膳立てが必要ではあります。きちんとレクチャーをし、プレビュー機能や、バックアップ機能などを十分に完備することが必須となるでしょう。

CMS

同じような需要が企業のコーポレートサイトなどのCMSとしての用途です。

この分野では WordPress が圧倒的な人気がありますが、Javaエンジニアが中心の会社で自社のサイトを作ったりするなら、わりとMayaaそのものを使うことは選択肢でありだと思います。

HTMLジェネレータとして使う

イレギュラーな話ですが、Mayaaをスタンドアロンなテンプレートエンジンとして使うテクニックが有ります（後日詳しく紹介します）

これを使うと、一つのテンプレートにデータを流し込んで静的ページ群を大量生成して出力すると結構便利だったりします。

さすがに出力対象がHTMLでない場合はあまり便利ではありませんが、マニュアルやドキュメントなどを大量に生成するとき、結構重宝します。

まとめ

こうしてみると、ある元データがあって、ビューという箱に収める・大量にページを生成するといった用途こそ、Mayaaが本領を発揮します。

本来であれば、XSLTのようでもあります。実際、XSLTの代わりにMayaaを使うと便利です。

MayaaをECサイトに使っているという事例は結構聞きます。でも、うまく使いこなすのは大変みたいですね。某企業みたいに本気で体制を組まないとつらそうです。

一方、マニュアルとか、自社CMSの用途なら比較的簡単かもしれません。その手のサイトを個人で作るときにMayaaを試してみるのも良いかもしれません。

ということで、明日はマニュアルの大量生成に挑戦してみようと思います！

MayaaでWebサイトのビューを実装するときに押さえておくべき基本テクニック5 – その他雑多なテクニック

いしがみメソッド5. その他テクニック

1.テンプレート上のコメントは、ソース表示時に見えないようにする

以前も紹介しましたが、テンプレート上に  形式でコメントを記載すると、HTMLなので、ソース表示でエンドユーザーに見えてしまいます。

JSPにおける　<%--, --%> のような記述に対応するためにはどうしたらよいでしょうか？

以前以下の様な方法を紹介しました。

<!-- ${/* このコメントは見えません */} -->

ただ、テンプレート上に${/* */}を書くことはできるだけ禁止したいことと矛盾します。また、${}の内側は初回アクセス時にJavaScriptとJavaにコンパイルしているので、ちりも積もればなんとやら。大量に書くのに向かないかもしれません。

テンプレート上に書いた"m:"名前空間の属性はサーバー実行時に消えます。なので

<div m:comment="これは○○です">
</div>

こういったテクニックも使えるでしょう。

もっとブロックで要素を隠したいときは、以下のようにDUMMY領域を囲むm:idを作成し

<m:null m:id='DUMMY_TAG' />

次のようにする方が見通しがよいかもしれません。

<div m:id="DUMMY_TAG">
  <div>....</div>
</div>

場面場面で適宜使い分けてください。

2.文言はなるべくテンプレート側に書く

ケースバイケースですが、例えば男性か、女性かを返すm:id

<m:with m:id="SEIBETSU_HERE">
  <m:if test="${user.sex == 'm'}"><m:write valus="男性" />
  <m:if test="${user.sex == 'f'}"><m:write valus="女性" />
</m:with>

などを作るくらいなら

<m:if m:id="IF_MAN" test="${user.sex == 'm'}">
  <m:echo><m:doBody /></m:echo>
</m:if>
<m:if m:id="IF_WOMAN" test="${user.sex == 'f'}">
  <m:echo><m:doBody /></m:echo>
</m:if>

を作りましょう。

ただ、文言を動的に組み立てるような場合は、この限りではないので、適宜対応してください。

3.nekoHTMLパーサーをいじる

上級者向きですが、スマホサイトを作ろうとする場合は実質必須でしょう。くわしくはMayaaでHTML5のスマートフォンページを作る際にはまったことの内容のとおりです。

まとめ

いかがでしたか？ここまでのテクニックはこれまでにこのブログや勉強会のスライドで紹介したことです。しかし、一つ一つじっくり説明したのは初めてだと思います。

これらテクニックはテンプレートエンジンがMayaaだけでなく、Mixer2などの別のテンプレートエンジンでも通用するのではないかと思います。Mayaaアドベントカレンダーで言うのもあれですが、たとえ将来Mayaaが忘れられても、覚えてほしいと思います。

僕が経験で培ってきた細かなテクニックを世に残せてよかったです。

次回以降予告

明日からは、これらのテクニックをふまえたMayaaの拡張や、細かな開発補助ツール、フレームワークとの組み合わせなど、どんどん紹介していこうと思います。

10日は、Java EEアドベントカレンダーの当番でもあるので、合流して、Java EEとMayaa両方に関係ある何かを書きます！

明日からもよろしくお願い致します。

MayaaでWebサイトのビューを実装するときに押さえておくべき基本テクニック4 – ヘッダー・フッター共通部分の扱い

いしがみメソッド4. ヘッダー・フッター・共通部品はiframeタグをうまく使う

テンプレートエンジンの必須機能として、ヘッダーやフッターなどの共通部品を実現する、includeとかimportとかの機能があげられるでしょう。Mayaaではこれをコンポーネントと呼び、insertプロセッサーによって実現します。

使い方は公式サイトの通りですので割愛します。

ここではこれを実際に使うときの問題点とテクニックを紹介します。

問題点1: 親のテンプレートを直接開いた時、コンポーネントの部分が見えない

例えば、common.HEADER_HERE, common.FOOTER_HEREという名前でヘッダ・フッタを出力するm:idを発行したとします。（m:id名の分類はHEREになります。デザイナーから見たら「何かが」出力されることはwriteでもinsertでも同じだからです）

使う側はこの世になるでしょう

<div m:id="common.HEADER_HERE">
ここにヘッダが表示されます。
</div>
メインコンテンツ
<div m:id="common.FOOTER_HERE">
ここにヘッダが表示されます。
</div>

このテンプレートをサーバーで実行すると、ヘッダー・フッターの部分に共通部品が表示されます。しかし、テンプレートファイルを直接開くと

ここにヘッダが表示されます。
メインコンテンツ
ここにヘッダが表示されます。

となってしまってなんだか簡素です。サーバーに上げなくてもデザインの確認ができるMayaaの良さが半減しています。

解決案1: divタグの中身を都度書く

一番単純な方法は、ヘッダ・フッタテンプレートのソースコードをコピペしてdivタグの中身に書いてしまうことです。

<div m:id="common.HEADER_HERE">
<h1>○○のサイト</h1>
</div>
メインコンテンツ
<div m:id="common.FOOTER_HERE">
<small>copyright (c) 2015 susumuis.info</small>
</div>

この方法は確かにデザインを確認することができましが、共通部品のデザインを変更すると、都度すべてのテンプレートを書き換える必要があって、作業量が爆発します。この方針はダメですね！

解決案2: iframeタグをうまく使う

それではどうするかというと、おすすめなのがiframeタグです。
iframeタグはまさしく、HTMLの仕組みだけで、ページのコンポーネント化を実現する機能です。が、実際にはあまり積極的に使われません。

そんなiframeタグにinsertプロセッサーを適用すると、
* ローカルプレビュー時はiframeで見た目の確認ができる
* サーバーで実行した時は直接内容が書かれている
ということが実現できます。

呼び出し元のテンプレート側にはこのように書きます。

<iframe m:id='common.IMPORT_HERE></iframe>

ただ、これだけでは、ページを開いた時に、スクロールバーが出てしまいます。iframeは縦横サイズが固定だからです。

そこで、JavaScriptで魔法を書けます。jQueryを使用している前提で書くとこうなります。

$(function() {
    $('iframe[m\\:id="common.HEADER_HERE"]').load(
        function() {
            $(this).attr('frameborder', "0")
                .attr('scrolling', "no")
                .attr('width', "100%")
                .css('height', this.contentWindow.document.documentElement.scrollHeight + "px");
    });
});

これでロードされた際に、縦横サイズが画面にピッタリフィットするようになります。これで大体の場合OKです。

ただし、chromeのみ、この方法では上手く行きません。fileスキーマでアクセスした時、iframe内のDOMにアクセスすることが制限されてしまうためです。起動オプションを都度付けることが出来るなら、次の起動オプションを付けて起動することで制限を回避することが出来ます。

–allow-file-access-from-files

あるいは、簡易的なWebサーバーを立ててしまって、httpプロトコルでアクセスする方法もあります。

iframeタグのsrc属性をそのままinsertプロセッサーのpath属性にしてしまう

この方法で、common.HEADER_HERE, common.SIDEBAR_HERE, common.FOOTER_HEREなどの部品を都度、default.mayaaの中に登録しても良いのですが、更に前回紹介したテクニックを使用して、iframeタグのsrc属性のパスをそのままinsertプロセッサーのpath属性に突っ込むm:idを作ってしまいましょう。これさえあればどんなページのm:idの追加することなくコンポーネント化できます。

事前に以下のような関数を作っておきましょう。

function getDirectory(path) {
    return path.subatring(0, path.lastIndexOf("/"));
}

<e:insert m:id='common.IMPORT_HERE'
        path='${getDirectory(Packages.org.seasar.mayaa.impl.engine.EngineUtil.sourcePath) + $p("src")}' />

便利だよ＼(^o^)／

ただし、このテクニックは、TemplateSuffixに"/"があるケースでは、上手く動かない時があります。はじめから、TemplateSuffixに"/"を使うテクニック
は使わないようにしましょう。

参考

susumuis Info

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