SSIについて

SSIそのものについては周知の事と思いますが、 HTMLのコメントノードを使ってサーバ側でコンテンツをインクルードする仕組みです。 例えば、HTML内に次のようなコメントを書いておきます。

<!--#include virtual="/common/header.html"-->

そうすると、サーバ側で自動的に /common/header.html をその部分に読み込んだHTMLを吐き出してくれます。

Apache等のSSIに対応したWebサーバで閲覧すれば良いだけの話ですが、 その為にApacheを用意するのもいささか面倒に感じる事もあるでしょう。

GruntでSSIしてみる

まずは Grunt の grunt-contrib-connect を使ってSSIを再現してみます。 middleware オプションを使ってサーバ側で置換してしまいます。

grunt.initConfig({
    connect: {
        dev: {
            options: {
                base: "html",
                port: 8080,
                keepalive: true,
                /* ↓ これを使います */
                middleware: function(){ ... }
            }
        }
    }
});

まず必要なモジュールを読み込んでおきます。

var fs = require("fs"),
    path = require("path"),
    url = require("url");

middleware の実装は以下のようにしました。

middleware: function(connect, options, middlewares){
    middlewares.unshift(function(req, res, next){
        var pattern, root, file, html;

        pattern = /<!--#include\s+?(virtual|file)="(.+?)".*?-->/g;
        root = options.base[0];
        file = path.join(root, url.parse(req.url).pathname).replace(/\/$/, "/index.html");

        if(/\.s?html$/.test(file) && fs.existsSync(file)){
            html = fs.readFileSync(file, "utf-8").replace(pattern, function(a, key, value){
                var inc = (key === "virtual") ? path.join(root, value)
                : path.join(file.replace(/[^\/]+$/, ""), value);
                return fs.existsSync(inc) ? fs.readFileSync(inc) : "";
            });
            return res.end(html);
        }
        return next();
    });
    return middlewares;
}

1. 拡張子が .html あるいは .shtml の時だけ処理します
2. SSIのパターンを見つけたら、該当ファイルを読み込んで差し替えます
3. 該当ファイルがなければなにもせずに静的ファイルを吐き出します

試してませんが、Gulpでも同じ事が出来るでしょう。

なお、#include のみ処理し、#set や #echo 等の他のコマンドは全スルーしております。 これらも使いたい場合は node-ssi 等を使ってmiddleware内でパースすると良いと思います。 （さすがに exec コマンドはサポートしてなさそうですが…）

SSIが見られるのは主に大きめのWebサイトのテンプレートですが、 経験上 #include 以外が使われているケースはほとんど見られません。

フロントでSSIしてみる

すでにSSIじゃなくなってますが、フロント側（JavaScript）でSSIを再現してみます。 むりやり名前をつけるならばFEI（フロントエンドインクルード）とかになるんでしょうか…。 とはいえ、XHRを使う都合上なんらかのサーバを通して確認する事になります。

先に申し上げておきますと、全くおすすめはできません。 特にJavaScriptも絡んだページ制作では、かなりの悪影響が予想されます。 当然本番で使用するのはもってのほかなので、ただの実験の記録として読み流してください。

パターン1: innerHTMLで強引に

ページ末尾でこのようなコードを実行してみました。

(function(){
    var body = document.getElementsByTagName("body").item(0);
    body.innerHTML.replace(
        /<!--#include.+?(?:file|virtual)="(.+?)".*?-->/g,
        function(key, value){
            var xhr = new XMLHttpRequest();
            xhr.open("GET", value);
            xhr.addEventListener("readystatechange", function(e){
                if(this.readyState === 4 && this.status < 400){
                    body.innerHTML = body.innerHTML.replace(key, this.responseText);
                }
            });
            xhr.send();
        }
    );
}());

innerHTML にはコメントも含まれているので、それらを強引に文字列置換してしまって差し替えています。 やさしさがかけらもない、ひどいコードです。 このコードの最も大きなデメリット（いや、デメリットしかありませんが）は、 要素に結びつけたJavaScriptが全く動かなくなる点でしょう。

document.getElementById("my-button")
.addEventListener("click", function(){
    console.log("click");
});

このような処理が書いてあったとしても、これは全く動きません。 innerHTML を書き換えると同時にDOMを破壊してしまい、上で参照している #my-button という要素とのつながりが断ち切られてしまう為です。

パターン2: DOMインターフェースを使って

ページの末尾で次のようなコードを実行します。

(function(){
    var each = function(list, callback){
        return Array.prototype.forEach.call(list, callback);
    };

    var parseSSI = function(nodes){
        each(nodes, function(node){
            var match, xhr;

            if(node.childNodes.length){ return parseSSI(node.childNodes); }
            if(node.nodeType !== 8){ return; }

            match = node.nodeValue.match(/#include.+?(?:virtual|file)="(.+?)"/);

            if(match){
                xhr = new XMLHttpRequest();
                xhr.open("GET", match[1]);
                xhr.addEventListener("readystatechange", function(){
                    if(this.readyState !== 4 || this.status >= 400){ return; }
                    var tmp = document.createElement("div");
                    tmp.innerHTML = this.responseText;
                    each(tmp.childNodes, function(child){
                        node.parentNode.insertBefore(child, node);
                    });
                });
                xhr.send();
            }
        });
    };

    parseSSI(document.getElementsByTagName("body"));
}());

body配下にぶら下がっている要素をすべて走査して、 コメントノード（nodeType === 8）だった場合にパターンと照合して処理します。

こちらのパターンはDOMを破壊しませんが、不完全なHTMLをモジュールとして読み込んだ場合に、それを補完してしまう欠点があります。 例えば次のような部品を読み込んだ場合。 （古き掲示板CGIのテンプレートを彷彿とさせる構成ですね）

<!-- header.html -->
<header>
    <h1>...</h1>
    <nav>...</nav>
</header>
<article>
<!-- /header.html -->

ここにコンテンツがはいります。

<!-- footer.html -->
</article>
<footer>...</footer>
<!-- /footer.html -->

不完全な要素が補完されてしまう為、想定と異なる構成になってしまい、当然見た目も崩れてしまうでしょう。

このような使い方をしなければ、SSIを模した形のモジュールライブラリとして使い様があるか…？とも考えましたが、 DOMを全走査しなければならない為、コスト的にあまり良策とは言い難いですね。 改善策はなくもなさそうですが、「そこまでやる必要がどこにあるのか」と考えてしまったのでそこで放棄いたしました。

まとめ

SSIの環境が必要になるケースは今後もまだなくなりはしないと思います。 そういった案件に限って1ページのみの制作という事もよくある話なので、 出来るだけ手元の環境でさくっと再現してしまいたいですね。

HTTPでアクセスしてチェックしたいケースとは

Webページを制作している時、多くの場合はそのままブラウザで開けば動作チェックが出来ますが、 サーバーを通してHTTPでアクセスしないと正常に動作しないケースもあります。

つまり、「file:～」ではなく、「http:～」でアクセスしたい。例えば、

• ChromeからAjaxのテストをしたい
• 各種ウィジェットのスクリプトの表示をチェックしたい

Chromeのケースは起動オプション（”–allow-file-access-from-files”）で解決できますし、 ウィジェットもスクリプトの中身を少しいじれば動くことが多いですが、 いずれもWebサーバーを通せば難なく動作するわけで、それがすぐに出来るのならばその方がシンプルではないかな、と思うわけです。

ではどうしようか

既にXAMPP/MAMPPや仮想マシン等でサーバ環境がある場合は良いのですが、 バーチャルホスト等の諸設定をこなすのが面倒くさかったり、とにかくささっと確認したいような場合は、 簡易的なサーバを利用してのチェックがお勧めです。

サッと起動して、サッ確認し、終わったらサッと終了する。

ここでは、3つの方法を提案してみます。

1. SublimeServerでチェックする
2. PHP5.4+のビルトインサーバーでチェックする
3. ローカルプロキシでチェックする

SublimeServer でチェックする

もし貴方がSublime Text 2を使って制作をしているのならば、これを使わない手はないでしょう。 Sublime Serverは、Sublime Text 2で動作する簡易Webサーバープラグインです。

SublimeServer

learning/SublimeServer

Allow you run a HTTP Server in SublimeText 2, and serves all the open project folders

メリットは、作業環境からすぐに実行できる点ですね。

インストール

1. 「Sublime Package Control」をインストール
2. コマンドパレットから 「Install Package」>「SublimeServer」 と打ち込む

※プラグインの導入法については以前書いた記事などをご参考に

使い方

1. 「Tools」>「SublimeServer」>「Start SublimeServer」で起動
2. 確認したいHTMLファイルを開いて、右クリックし、「View This File in Browser」

これで、デフォルトのブラウザで目的のファイルが開かれます。 URLは以下のようになります。プロジェクトがルートディレクトリのような扱いになっていますね。

http://localhost:8080/[folder name]/index.html

ポート番号の「8080」は、「Tools」>「SublimeServer」>「Settings」 で変更できます。

PHP5.4+のビルトインサーバーでチェックする

マシンにPHP5.4以降がインストールされているのあらば、 PHPにビルトインされている簡易Webサーバーが利用できます。

PHP: ビルトインウェブサーバー – Manual

メリットはPHPの動作チェックが出来る点ですが、 簡易的な物なのでrewrite等は動かず、そこらへんに依存するFW等の動作は難しいでしょう。 そういう大掛かりな物は、きちんと仮想環境を構築してテストしましょう。

使い方

※PHP5.4以降が導入済みで、パスが通っている前提で話を進めます。

1. ターミナル（あるいはコマンドプロンプト）を開く
2. 
   

   目的のファイルがあるディレクトリまで移動して、以下のコマンドを実行する

   
   

   php -S localhost:8080

   
   
3. 
   

   ブラウザを開いてアドレスバーにURLを入力する

   
   

   http://localhost:8080/index.html

   
   

実行したディレクトリがルートディレクトリの扱いになります。

ローカルプロキシでマッピングする

これは前述した2つの方法と違い、ローカルでWebサーバーを起動するのではなく、 ローカルプロキシを利用して、或るドメインへのアクセスをローカルのファイルにマッピングする方法です。

…と言ってもピンと来ないですね。

例えば、「http://example.com/index.html」というファイルへブラウザでアクセスするとして、 その「index.html」の内容を、ローカルにあるファイルに差し替える事が出来ます。 そうすることで、あたかもインターネット上にそのファイルがあるかのように振る舞ってくれるわけですね。

Charles

ここでは、ローカルプロキシツールのCharlesを使ってみます。 有料ではありますがクロスプラットフォームで開発されていて、Windows/Mac/Linux版が用意されています。

Charles Web Debugging Proxy • HTTP Monitor / HTTP Proxy / HTTPS & SSL Proxy / Reverse Proxy

使い方

1. 「Tools」>「Map To Local」で設定ダイアログを開きます
2. 「Add」で新しくマッピングを作成します
3. 
   

   下記のような要領で入力して「OK」

   
   

   

   
   
4. 
   

   設定したURLにアクセスします

   
   

   http://local.test/index.html

   
   

ドメインは、名前解決が出来る必要があります。 プロジェクトに使用する予定のドメインを使うか、適当な「local.test」などの名前をあてがってhostsファイルに127.0.0.1などで書き込んでおくか、 あるいはexample.comやlocalhostを利用するなどしましょう。

まとめ

これらの方法は、DirectoryIndexが指定できなかったりパフォーマンスが悪かったりする為、あくまでも簡易的なチェック向けです。 が、それで十分な場合は多いに制作の手助けになってくれる事でしょう。

特にローカルプロキシは、こういったケースに因らず、様々なシーンで開発効率をあげてくれるので、 （むしろそちらの方がメインですね） ぜひとも導入しておくべきだと思います。

パフォーマンスの差

具体的にどれくらいパフォーマンスが変わるのかというと…
モバイル回線のノートでYahoo!のトップページを取得してざっくり計測したところ、

• file_get_contents : 4秒前後
• cURL : 2秒前後

概ねこんな感じとなりました。
勿論時間帯や回線など様々な要因にもよりますが、
ちょっと無視出来ない数字ですね。

cURLを使う

簡単な使い方

cf) PHP: cURL – Manual

1. curl_init()で初期化
2. curl_setopt()でオプションを設定して
3. curl_exec()で実行
4. curl_close()で終了

というのが一連の流れです。
curl_setoptで渡すオプションにより、cURLさんにどんな動作をさせるのかを設定します。

$url = "http://www.example.com";
$ch = curl_init(); // 1. 初期化
curl_setopt( $ch, CURLOPT_URL, $url ); // 2. オプションを設定
curl_setopt( $ch, CURLOPT_RETURNTRANSFER, true );
$result = curl_exec( $ch ); // 3. 実行してデータを得る
curl_close(); // 4. 終了

オプションについて

オプション一覧
cf) PHP: curl_setopt – Manual

今回使うものだけ軽くメモ。

CURLOPT_URL

アクセスするurlです。これがないと始まりません。

CURLOPT_HEADER

ヘッダ文字列を一緒に出力するかどうかのBoolean値。
邪魔なのでfalseにします。

CURLOPT_RETURNTRANSFER

curl_execの返り値を文字列にする為のBoolean値。
これをtrueにしてやらないと、データが直接出力されます。

CURLOPT_TIMEOUT

cURLさんに頑張ってもらう秒数です。
これを超えると諦めてfalseを返します。

関数にまとめてみる

簡単に使えるように関数にまとめてみます。

function curl_get_contents( $url, $timeout = 60 ){
    $ch = curl_init();
    curl_setopt( $ch, CURLOPT_URL, $url );
    curl_setopt( $ch, CURLOPT_HEADER, false );
    curl_setopt( $ch, CURLOPT_RETURNTRANSFER, true );
    curl_setopt( $ch, CURLOPT_TIMEOUT, $timeout );
    $result = curl_exec( $ch );
    curl_close( $ch );
    return $result;
}

// test
$result = curl_get_contents( "http://www.example.com", 120 );

第二引数はタイムアウトの秒数です。

おわりに

オプションを見るだけでも分かるように、cURLは他にも相当色々な事が出来そうです。
「Curl」だと別のプログラミング言語の事をさしてしまうので注意。

• cURL公式
• cURL – Wikipedia

Learning jQuery – Tips, Techniques, Tutorials

簡単な仕組み

ネタ元はこの記事です。
Detecting Ajax Events on the Server » Learning jQuery – Tips, Techniques, Tutorials

どうやらjQueryはXmlHttpRequestでリクエストをする際に
「X-Requested-With」というヘッダに
「xmlHttpRequest」という値を格納しているそうな。
jQuery…なんという愛でしょう。

jQueryの素晴らしさを実感すると同時に、
やはり一度はソースを熟読しておくべきだなぁと感じますね。
参考になる設計手法とか、恐らく随所に見られる事でしょう！

取得してみる

PHPとRubyで、試しに取得してみました。

PHP

$xhr = ( @$_SERVER["HTTP_X_REQUESTED_WITH"] === "XMLHttpRequest" );
echo ($xhr) ? "jQuery Ajax" : "Requested Directly" ;

Ruby

xhr = ( ENV["HTTP_X_REQUESTED_WITH"] === "XMLHttpRequest" )
print (xhr) ? "jQuery Ajax" : "Requested Directly"

ちなみにこのヘッダが渡されるのは、あくまでもXMLHttpRequestを介して行われた通信だけです。
それ以外のもの、例えばJSONP等の場合は渡されないので注意しましょう。
（JSONPはscript要素を追加しているだけなので、XMLHttpRequestは使用していません）
cf) jQueryはJSONPの理解の妨げになるか？

ネタ元のブログも素晴らしいです！
今回初めて知ったのですが、是非とも全てに目を通したいです。
Learning jQuery – Tips, Techniques, Tutorials

VI Editor / Linux Terminal Cheat Sheet (PDF) – Smashing Magazine

こんなかんじに綺麗にまとめられています。
リンク先ではPDFにてダウンロード出来るので、印刷して目につくところに貼っておくと便利。
私も本当に限られた機能しか使っていなかったので、重宝しそうです。

VIのチートシートとしては、このグラフィカルなやつも結構有名ですね。

Graphical vi-vim Cheat Sheet and Tutorial

これはデスクトップの壁紙にして使えそう。

この手のチートシートで日本語で書かれたものはあまり見かけないですが、
必要とする人の多くが英語で十分だと感じているからでしょうか。
それとも面倒だからでしょうか。（まぁもちろん面倒ですが！）

面倒くさがりやの私は感謝の気持ちを胸に、
ありがたく活用させて頂きたく思います。