作成者別アーカイブ: admin

JavaScriptがプロトタイプベース言語だということについて

オブジェクト指向言語も決して一枚岩でありません。西の横綱もいれば、西の高校生探偵もいます。このブログで扱う事の多いPHP、JavaScriptなどについて見てみますと、PHPはクラスベース言語というタイプに含まれるのに対して、JavaScriptはプロトタイプベース言語というタイプに含まれます。JavaScriptのプロトタイプベース言語の方が、幾分マイナーですので、こちらの特徴を追ってみましょう。

プロトタイプベース言語には、クラスの概念が無い

オブジェクト指向についてかじった事のある人間ならば、あらゆるものがオブジェクトで、そのオブジェクトには設計図たるクラスが必要で…といったようなオブジェクト指向のイロハに馴染んでいることと思います。一方JavaScriptが属するマイノリティ、プロトタイプベース言語には、オブジェクトの設計図たるクラスは存在しません。それでは、オブジェクトは何を元にして作られるのか、何を実体化してインスタンスをつくるのかという疑問が当然沸き上がる筈でしょう。

実は、JavaScriptにおけるインスタンス化は、既存のオブジェクトを丸々コピーすることによって行われます。コピー元もまた実体をもったオブジェクトなのです。

はい、メモリの無駄遣い発見!JavaScriptはとんだ低級言語だぜ!と思われた方は、オブジェクト指向の意義についてしっかりと理解された方だと思います。既存のオブジェクトをコピーするという方法では、もしプロパティやメソッドの実装部分が100個あったら、インスタンスそれぞれにつき100個を丸ごとコピーしなければなりません。それでは、毎度毎度新しいオブジェクトを一から作成しているのと何ら変わりません。そこで、プロトタイプ言語ではそうした問題を解決する方法として、プロトタイプオブジェクトという概念を用意しています。

JavaScriptでのクラス(仮)宣言

JavaScriptでクラスのようなもの、つまりインスタンスにコピーされるコピー元のオブジェクトを宣言する場合には、変数(クラス(仮)名)への関数リテラルの代入だけで済みます。

var Conan = function(){};

これで終わりです。右側に書かれた無名関数がコンストラクタになりますので、何かしらプロパティやメソッドを設けたい場合には、function(){}の中に書けば大丈夫です。

var Conan = function(powder){
this.powder = powder;
this.pero = function(){
if(this.powder == "青酸カリ"){
alert("これは…青酸カリ!");
} else {
alert("この料理を作ったのは誰だっ!");
}
};
};

これでクラス(仮)Conanにプロパティpowderとメソッドpero()ができました。インスタンスを作成する際に引数を与えることで、プロパティpowderを初期化できます。

var conan = new Conan("青酸カリ");
conan.pero();
 
//結果 これは…青酸カリ!

JavaScriptのプロトタイプ

さて、先ほど挙げた問題に戻ります。このままですと、Conanクラスのインスタンスをconan1,conan2,conan3…とどんどん作っていくことで、その都度powderプロパティとpero()メソッドの宣言が行われメモリの無駄になってしまいます。そこで、JavaScriptのクラス(仮)には暗黙のプロパティであるprototypeというものが用意されており、このプロパティ(正体はオブジェクト)への値の代入を行うことで、プロパティやメソッドの追加が行えるようになっています。

var Conan = function(powder){
this.powder = powder;
};
 
Conan.prototype.pero =  function(){
if(this.powder == "青酸カリ"){
alert("これは…青酸カリ!");
} else {
alert("この料理を作ったのは誰だっ!");
}
};
 
//宣言してもいないConanクラスのプロパティ prototype に値を入れてしまう

これで、先ほどと同じくインスタンスからメソッドを実行できるようになります。

どの辺りがメモリの節約になったのかと言うと、実はインスタンス側にはpero()メソッドがコピーされておらず、インスタンスからpero()メソッドが呼ばれると、インスタンスの持つprototypeオブジェクトへの参照を便りに、prototypeオブジェクト中の同名メソッドを呼ぶ仕組みになっているのです。
つまりどれだけプロトタイプ側にメソッドやプロパティを追加しても、インスタンス側にはプロトタイプへの参照しか残らないので、経済的だというわけですね。

いかがだったでしょうか。決してJavaScriptの属するプロトタイプベース言語が、クラスベース言語に劣った低級なものでないという事が分かったのではないでしょうか。実はプロトタイプベース言語はクラスベース言語へのアンチテーゼとして作られたという経緯があり、クラスベースのオブジェクト指向の弱点である、開発の段階が進むにつれて設計図であるクラスへの設計図としての要求が高くなってくる(→リファクタリングの必要性が出てくる)といったところをうまく解決して、機能の追加をアドホックに行えるという持ち味を醸しています。

ということで、JavaScriptは案外面白い奴です。


ハネムーン期間は終わりだ!WordPress3.5のメディアアップロードに対する不満

WordPress3.5を使用していて、それはあまりにもどうかと思う、という現象に出会ったので。

WordPressで投稿にメディアを追加するためには、投稿画面の”メディアを追加”ボタンをクリックし、各種メディアをファイル選択またはドラッグ&ドロップアップロードで登録、必要であれば名称やキャプションなどをつけた上で投稿に挿入するという手順になっている。

このとき、”添付ファイルの表示設定”というセクションで投稿記事中のサムネイルファイルの配置、大きさ、リンク先を指定するようになっている。そして、リンク先の選択肢はサムネイルの元ファイルである”メディアファイル”の他に、”添付ファイルのページ”も選べるようになっている。というか、私がアップデートしたWordPress3.5では、デフォルトで勝手に”添付ファイルのページ”が選ばれていた。

しかも、そのページはThickBoxを使うテクニックを使って、いわゆるlightBox的挙動をするように設定していたページだ。結果、ライトボックスのウィンドウに添付ファイルのページが表示されてしまうという、わけのわからない事態になっていた。

で、記事を投稿するときにつける画像に、いちいちライトボックスが正常に働いているか一つ一つチェックする人は少ないわけじゃない。私にしてもそういう物臭な人間だったため、WordPres3.5にアップデートしてからの投稿記事で、全ての画像のリンク先がページになっていた!

修正作業が面倒くさい。100点ぐらい画像ありますよ?いちいち一つ一つについてリンク先を画像ファイルに変えて、更新。しかもリンクのrel属性に添付ファイルページを識別する名前をつける仕様も好ましくないため、relの部分の指定も削らないといけない。

WordPress3.5にアップデートしてからGooglebotがよくこの添付ファイルのページのクロールエラーを報告してくるのだけど、このサムネイル画像からのrel指定のせいではないですかね。そもそもrel属性はnofollowをつけたりnext、prevなどのクローリングの最適化のために使うべきであって、勝手に謎な識別名の格納場所として使用してしまって良いのですか?

本当にこういう修正作業が空しくなります。やはり、万人のかゆいところに手が届くように作られたソフトウェアというものは、余計なところを掻きむしって使用者の皮膚をボロボロにする定めなのですかね。

そういう例は、本当によく見かけます。


PHPとJavaScriptでURLのクエリストリングを評価する

クエリストリングというのは、ほうぼうのWEBサービスでよく見かける、URLの後ろについた情報を持った文字列です。たとえば、youtubeで動画の検索をするとき、URLの後ろに ?search_query=検索文字列 として、URLにユーザ検索の内容をつけて遷移後のページに渡しています。
このクエリストリングは、search_queryのような普遍的な語でなくても、勝手な語を選んでつけることができます。そもそも、HTMLでフォームを作って送信方法にGETを選ぶと、input要素のユーザが設定したname属性がストリングになっていますね。またinput要素が複数の場合は、&で結ばれています。これもクエリストリングの特徴です。

さて、このクエリストリングをプログラム側でキー値と値の組で取得するにはどうすればよいでしょうか。

PHPでクエリストリング

PHPの場合、大抵の文字列操作は標準の関数として装備されています。本当に。自分で作る前にまず探してみると、大抵便利なのがあります。再発明した車輪はゴミの日にそっと出しましょう。

1.URL文字列からクエリストリングを取り出す場合
//このようなURLがあったとき
$url = "http://akisi.tabiyaku.net/index.php?query1=値1&query2=値2";
 
//クエリ部分を抽出する関数
$query = parse_url($url,PHP_URL_QUERY);
//$queryは"query1=値1&query2=値2"
 
2.現在のページのURLからクエリストリングを取得する場合
$query = urldecode($_SERVER["QUERY_STRING"]);
//urldecodeで、%E3みたいなコードになっているのをデコードする
 
3.取得したクエリストリングをキーと値の組に
parse_str($query,$arr);
 
//$arr["query1"]は値1
//$arr["query2"]は値2

3で$arrを指定しなければ、通常の変数($query1,$query2)にそれぞれの値が入ります。

JavaScriptでクエリストリング

JavaScriptの場合には、車輪の開発者になる余地が大いにあります。何故PHPのような標準でクエリストリングを扱う関数が無いのでしょう?簡単な話です。JavaScriptは未来の言語だからです。未来の車には、車輪など必要ありません!

1.URL文字列からクエリストリングを取り出す場合
 
//このようなURLがあったとき
var url = "http://akisi.tabiyaku.net/index.php?query1=値1&query2=値2";
 
//クエリ部分を抽出する(処理的には、?を探して以降の文字列をとる)
var query = url.slice(url.indexOf("?")+1);
//queryは"query1=値1&query2=値2"
 
2.現在のページのURLからクエリストリングを取得する場合
var query = decodeURI(location.search);
//decodeURIで、%E3みたいなコードになっているのをデコードする
//ただし、先頭に?を含むところがPHPと異なるので、?なしで取得する場合
var query = decodeURI(location.search).substring(1);
 
3.取得したクエリストリングをキーと値の組に
var arr = new Array();
var qarr = query.split("&");
for(i in qarr){
arr[qarr[i].substr(0,qarr[i].indexOf("="))] = qarr[i].substr(qarr[i].indexOf("=")+1);
}
//arr["query1"]は値1
//arr["query2"]は値2

こういった具合です。

実はJavaScript自体の関数ラインナップはPHPより劣るものの、PHPと同様の充実度を誇るのがjQueryです。確実に世界のどこぞの誰かが、あなたより先に車輪を開発してプラグインにしています。たとえばクエリストリングの評価ならば、jquery.toObject.jsこちらを使えばよろしいでしょう。こんな何某のWEB制作日記とか言う場末ブログのブックマークは、今すぐゴミ箱に放り込みましょう。


小ネタ:WordPressがHTML5に対応して、過去記事の見出しに困る

WordPressはそのアップデートの歴史の中で、まさにアップトゥデートな技術を取り込み成長してきました。現在のヴァージョン3.5+Twenty Twelveでの売りはレスポンシブデザインですし、Twenty ElevenではHTML5対応という飛躍がありました。

さて、そうなると過去からずっとWordPressを使い続け、記事を投稿している人間にとっては、過去の投稿資産がアップデートで価値を失ってしまわないかと不安になります。何しろ新技術が過去の資産をラッピングして表示するわけで、何かしらの不具合になってもおかしくありません。

そうしたアップデートに伴い発生する不具合(不都合)の例を挙げましょう。Twenty ElevenでのHTML5対応により、HTML5の大きな特徴であるセクショニング・コンテンツの宣言と、セクション宣言の直後の見出しレベルh1からの使用が可能になりました。

それまで、Twenty Tenおよび他のHTML5未対応テーマでは、投稿記事のタイトルが<h2>から始まっていたため、あえて記事中で見出しをつける際には<h3>タグをルートレベルとせざるを得ませんでした。
ところがHTML5ではセクショニング・コンテンツの開始を宣言すれば、文書中のどの場所でも<h1>タグからの階層構造にする事ができます。そして、Twenty Eleven以降の標準テーマでは、投稿記事を<article>タグで囲んでセクショニングコンテンツとするとともに、記事タイトルを<h1>としているのです。

そこで、Twenty Eleven以降のテーマで過去の記事を表示すると、記事タイトルの<h1>タグの下に”空気を読んで”<h3>に揃えておいた見出しタグが来てしまいます。<h2>タグのない、崩れた構造になってしまいます。

WordPressの売りは、テーマの自由自在な変更に代表される、深く考えなくても良いカスタマイズ性だったはずですが、HTML5へのステップアップを挟む事で、記事本文のテーマからの独立性が保証されなくなったと言えます。いまや、そのテーマが記事でどの見出しタグをルートとしているかあらかじめ知っていないと、無闇にテーマを変更する事ができなくなっているのです。

何が言いたいのかというと、投稿記事の見出しを<h3>タグで始める、手癖がついてしまっているのですよね。困った。

こうしたステップアップを挟んだからか、WordPressのテーマプレビュー(Lorem ipsum…)でサンプル文章中に<h1>、<h2>タグも含まれているのですが、特にこれにスタイルを設定していないテーマもよく見かけます。

誰に腹を立てたら良いのか、怒りのやりどころもわからぬままポチポチ過去記事を修正です


File API FileReaderを使った画像のドラッグ&ドロップアップロード

HTML5で新たに搭載されたAPIを利用して、WordPressのメディアアップロード画面のようなドラッグ&ドロップでの画像アップロード機能を実現します。File APIのFileReaderとData URLを使ったAjax POSTの手順は、以前OnlyCSViewを作成したエントリを参考にしていただくとして、今回はさらにドラッグ&ドロップAPIを使ったローカルファイルのセットと、PHP側での受け取ったData URLの保存方法を説明します。

STEP0:HTML5におけるページ内要素のドラッグ&ドロップ

HTML5では、ブラウザ上でのネイティブのドラッグ&ドロップを実現させるための属性として、draggableおよびdropzoneが用意されました。理想的には、draggable=”true”と指定されたページ上の要素をぐぐっと掴んで、dropzone属性の指定がされた要素の上に移動できるという動作の実現が期待されているのですが、dropzone属性に対応しているブラウザがほぼ無いため、ドロップ側の挙動はJavaScriptで実装するしかありません。とりあえずJavaScriptは置いておいて、属性指定だけした動作サンプルを見てみましょう。

draggable=”true”を指定した要素
(対応ブラウザならぐぐっと掴める)
dropzone=”move”を指定した要素
(対応ブラウザならドラッグした要素を
ドロップで受け付ける)

これがページ内要素のドラッグ&ドロップです。おそらく動作していないでしょう(笑)。ちなみにdropzone属性の値は、ドラッグ中の要素を移動させる”move”以外にも、複製する”copy”、ドラッグされた要素のリンクを取得する”link”などがあります。絵に描いた餅ですね。

STEP1:ローカルファイルのドラッグ&ドロップ

今回作成するプログラムのように、ローカルファイルをドラッグ&ドロップする場合には、ドラッグ側にdraggable属性を設定しなくてもOS標準機能でドラッグができています。ただし、通常ブラウザ上にファイルをドロップしたときの処理は、例えば画像ファイルやテキストファイルであればウィンドウ全体を使ったプレビュー表示になりますので、この標準処理をドロップ側でキャンセルし、別の処理をイベントに紐づける必要があります。もちろんJavaScriptを使うことになります。

STEP2:ドロップを受け付ける要素を用意してAjaxイベント付加

では、ドロップを受け付ける要素にdropzone属性の代わりとなるイベントをつけましょう。

//jQueryのCDNでのインポート。ヴァージョンはあまり気にせず。
<script src="http://code.jquery.com/jquery-1.7.2.min.js"></script>
.
.
<script type="text/javascript">
$(function(){
//jQueryに無いイベントdataTransferを付加
$.event.props.push("dataTransfer");
 
//ドロップを受け付ける領域は、適当にclass名をdropzoneとしておく。
var dropzone = $(".dropzone");
 
//FileReaderオブジェクトが無いとそもそも動作しない
//非対応ブラウザではdropzoneをそもそも表示しない心遣い(必須ではありません)
if(!window.FileReader){
          dropzone.hide();
          return false;
        } else {
//心遣いしないのなら、本処理はここから
		dropzone.bind("dragover",function(event){
			event.preventDefault();
			event.stopPropagation();
			return false;
		});
//領域にファイルが入ったら、灰色にハイライトさせる心遣い(必須ではない)
		dropzone.bind("dragenter",function(event){			
			$(this).css("background-color","#CCC");
			return false;
		});
		dropzone.bind("dragleave",function(event){
			$(this).css("background-color","#FFF");
			return false;
		});
//心遣い終わり
 
//本処理
		 var handleDroppedFile = function(event){
			 var thisarea = $(this);
          var file = event.originalEvent.dataTransfer.files[0];
		  var type = file.type;
          var fileReader = new FileReader();
		  fileReader.readAsDataURL(file);
          fileReader.onload = function(event){
 
//心遣い担当
            thisarea.css("background-color","#FFF");
//終わり
			$.ajax({
				type : "POST",
				url : "dropupload.php",
				data: {"type" : type,
"data" : event.target.result},
				success : function(data){
//成功処理を書くならここに。"成功しました"と表示させるとか			
				},
				dataType : "json"
			});
		  }
		  fileReader.onerror = function(stuff){
//心遣い担当
            thisarea.css("background-color","#FFF");
//終わり
		  }
		  event.preventDefault();
		  event.stopPropagation();
          return false;
        }
		   dropzone.bind("drop", handleDroppedFile);
		}
});
</script>

dropzoneには$.bindでもってイベントを結びつけます。ここでは”dragover”,”dragenter”,”dragleave”,”drop”の4種類が出てきますが、領域にファイルが重なったときに処理を行わないのなら、”dragover”と”drop”だけで良いでしょう。dragoverでは、ファイルをブラウザのウィンドウ上にドラッグしたときの標準処理をpreventDefaultでキャンセルし、stopPropagationでイベントが下位要素にも伝わってしまうのを止めます。ちなみに、IEの場合下から上にイベントが伝わっていくらしく、またメソッドではなくプロパティで指定する(event.returnValue = false;/event.cancelBubble = true;)ようです。IE10ではFileReaderがサポートされるみたいなので、対応の手間が増えますね。

fileReaderからreadAsDataURLでファイルをDataURLにする辺りは、以前OnlyCSViewを作成したエントリを参考。今回は$.postではなく$.ajaxを使っているので注意です。

STEP3:PHP側でアップロードの実装

PHP側では、Data URLにされた画像の解凍に一手間が要ります。

//dropupload.php
 
<?php
$filetype = htmlentities($_POST["type"], ENT_QUOTES, "UTF-8");
if(preg_match("/jpeg/",$filetype)){
$filesuffix = ".jpg";
$mimeprefix = "data:image/jpeg;base64,";
} else if(preg_match("/gif/",$filetype)){
$filesuffix = ".gif";
$mimeprefix = "data:image/gif;base64,";
} else if(preg_match("/png/",$filetype)){
$filesuffix = ".png";
$mimeprefix = "data:image/png;base64,";
}
 
//とりあえず一意の名前になってほしいので、日付時刻をコピー先ファイル名にする。
 
$filename = date("YmdHis").$filesuffix;
 
//まあ、仮にアップロード画像を格納するディレクトリがuploads/だったとしたら
$filepathname = "uploads/".$filename;
 
file_put_contents($filepathname,base64_decode(str_replace($mimeprefix, '', $_POST["data"])));
?>

エラーのコールバック処理を入れなければこういう感じです。
base64_decodeという関数でData URLのbase64エンコードを解凍するのですが、このときURLのファイルタイプ部分を取り除いてやらないと、PHP側でうまくコピーできないというのがキモですよ。


PHPのforeachループで配列の要素を評価、除去する

今回はPHPの小ネタです。

PHPのforeachは、配列内の要素一つ一つに対して同じ処理を適用する際に便利です。構文は、以下の二種類です。

//構文1
foreach(配列 as 値を入れる変数){
処理
}
 
//構文2
foreach(配列 as キー値 => 値を入れる変数){
処理
}

構文1では配列内要素の値をそのまま順番に取得して変数に入れます。たとえば、”りんご”,”ごいさぎ”,”ぎんやんま”という3要素をもつ配列$Septemberがあったとき、

foreach($September as $value){
$value .= "?";
echo $value;
}

結果、りんご?ごいさぎ?ぎんやんま?が出力されます。これはあくまで値を変数に格納しているだけですので、元の配列$Septemberを処理終了後ダンプしてみても、内部の要素は”りんご”,”ごいさぎ”,”ぎんやんま”のままです。
元の配列の要素を変更する場合は、構文2を使います。

foreach($September as $key => $value){
$September[$key] .= "?";
}

これで$Septemberをダンプすると”りんご?”,”ごいさぎ?”,”ぎんやんま?”となっています。
この挙動は、元からキー値つきで宣言された配列に関しても同じです。

$September = array("果物" => "りんご","鳥" => "ごいさぎ","虫" => "ぎんやんま");
foreach($September as $key => $value){
$September[$key] .= "?";
}
 
//$Septemberは("果物" => "りんご?","鳥" => "ごいさぎ?","虫" => "ぎんやんま?")

配列の要素の改変についてはこれでOKですが、配列の要素を評価して削除する場合にはどのようにすればいいのか。要素を削除することでループのインデックスが変わってしまって不都合になるのではないかと心配しましたが、思いつくままunsetを使って、特に問題ない結果を得られました。

foreach($September as $key => $value){
if($September[$key] == "ごいさぎ"){
unset($September[$key]);
}
}
 
//$Septemberは、("りんご","ぎんやんま")

ただし、この場合配列のインデックスが歯抜けになってしまいますので、連番のインデックスに戻したい場合には、array_values関数を使わないといけません。
カンマ区切りで保存してあるデータを取り出し、explodeしたあとforeach内で評価、特定の値のものを削除してimplodeで元に戻す。といった処理の流れで使えそうです。


サイトC:WordPress3.5&Twenty Twelveに変更

去る2012年の12月、WordPressのヴァージョン3.5が正式リリースになりました。

このブログでは、WordPressをヴァージョン2.9から使用しており、大きなアップデートとしては3.0へのアップデートを一回経験しています。以降は小数点以下のアップデート経験しか無いのですが、ヴァージョン3.4へのアップデートあたりから、3.0リリースの補完的アップデートとは異なった新たなWordPressへの脱却を感じさせるアップデートになってきたという印象があります。今まではWordPress以外のWEBアプリケーションの機能をなぞるような意気だったのが、最近ではWEBアプリケーションのトップをひた走るという自負すら見えてくるといいますか。たとえば、3.4でMovableTypeやBlogger由来のAPIを使わなくても、自前のAPIだけでxml-rpc投稿ができるようになったことなどが例として挙げられましょう。

とは言え、あまりWordPressの機能を使い込んでいない人間からすれば、そうした目に見えないアップデートはさして重要ではありません。
今回のアップデートの目玉の一つは、デフォルトテーマのTwenty Elevenのグレードが一つあがり、Twenty Twelveに生まれ変わったことです。このブログでも早速(いや、単体では8月あたりにリリースになっていたことは知ってますよ)導入してみました。

Twentyシリーズはヴァージョンアップのたびに目玉仕様を乗っけてくるのですが、Twenty ElevenがHTML5への対応だったのに対し、今回のTwenty TwelveはRetina対応とレスポンシブデザインとなっています。確かにTwenty ElevenをiphoneやiPadで見たときの間延び感は気になっていたので、アップデート後真っ先にその点をチェックしてみましたが、そつのないスッキリとしたデザインに統一されています。

iPadでのTwenty Twelveテーマ

iPadでのTwenty Twelveテーマ

ちなみに、余談ではありますがこのスクリーンショットを撮影するのに使ったchrome機能拡張は、Rippple Emulatorといい、各種スマートフォン、タブレットの縦横表示チェックの他、本体の振動やGPSもテストできる便利ツールです。

メニューがデフォルトで展開されず、ユーザアクションで開く形になったのがスマートフォンサイトっぽいですね。サイドバーは投稿下部に付き、Twenty Elevenのような面倒くさい設定も要りません。
今後はこれをたたき台にしたデザインのページが増えそうですね。