あんちもん2.Lab

『日付の言語』の設定を拡張！ - DateLangX プラグイン for MT4

2008-12-02T03:05:35Z

ニッチなニーズに応えられる（かもしれない）プラグイン、MT4対応版を公開します。 Movable Type (以下、MT) の、ブログ記事設定『日付の言語』を拡張する、DateLangXプラグインです。 MT4.0以降に対応しています（MT4.01、MT4.22で動作確認済み）。インストールすると、以下の図のように『日付表示用の言語』に項目が追加されます。 ※このプラグインは、MT4.x用です。MT3.xをご利用の方はこちらをご覧ください。

ダウンロード

(どちらかを選択してください。内容は同じです。)

ver.0.1 [New!]

DateLangX4MT4.zip[4,839 Bytes]
DateLangX4MT4.tar.gz[2,585 Bytes]

動作環境

MT4.0x以降（transformer利用）。 MT4.01、MT4.22 で動作確認を行っております。

インストール

ダウンロードしたファイルを解凍してください。
解凍ソフトに「ディレクトリ構造を**」というオプションがある場合は、「ディレクトリ構造を有効（再現、等）」にして解凍すると、以下のようなディレクトリ構造が生成されます：
```
DateLangX
  ┣DateLangX.pl
  ┗lib
    ┗DateLangX
      ┣L10N.pm
      ┗L10N
        ┣en_us.pm
        ┗ja.pm
```
解凍して得られた DateLangX フォルダごと、[MT]/plugins/ フォルダ内にコピー（アップロード）してください。

機能 - 日付の言語の拡張

インストールすると、ブログ記事設定（各ブログ→グランドナビの「設定」→「ブログ記事設定」、もしくは「設定」→「ブログの設定」→「ブログ記事設定」）の『日付の言語』に、いくつか項目が追加されます。 ver.0.1では、以下の2つが追加されます。

英語(日付 '/' 区切り)
日本語(日付 '/' 区切り)

例えば、『日本語(日付 '/' 区切り)』を選択し「保存」すると、以降ブログを再構築した場合、ブログの基本的な日付表記が「2008/12/02」のようなスラッシュ区切りになります。（拙作「DateSlashedFilter」の代替として使用いただけます。）

現在分かっている問題点

このプラグインは、現在のところ、ダイナミックパブリッシングには対応しておりません。よってダイナミックパブリッシング環境では、『日本語(日付 '/' 区切り)』に設定しても表示は日本語の通常の表示（例：2008年12月2日）になってしまいます。これを解決するには、MTのコアライブラリになる MTUtil.php を直接弄ってして改造しないとなりません。機会があれば、そのハック方法もご紹介したいと思います。（なおこの問題は、MT3用のDateLangXでも同様です。）

更新履歴

2007/01/20

(for MT3 ver.0.1 公開)

「英語(日付 '/' 区切り)」、「日本語(日付 '/' 区切り)」を提供

2008/12/02

for MT4 ver.0.1 公開 [New!]

MT4.x への対応完了。別アーカイブとして公開。

免責事項

Movable Type のユーザーは目的を問わず、このプラグインを無償で自由に利用することができます。著作権は Antimon2 が保持します。このプラグインは無保証です。このプラグインの利用によるいかなる損害にも作者は一切の責任を負いません。

継続的な開発をご支援くださる方は、よろしければドネーションをお願いいたします。

PayPal によるドネーション

丸1年ぶりの更新です。。。

2008-12-01T14:01:37Z

業務多忙を言い訳にかなーり更新さぼってしまいました。それに加え、業務ではJavaScriptがメインになってしまい、Movable Type からはしばらく遠ざかっていました。いろいろあったのですけれど、これから、少しずつ更新を再開します。表示がおかしいところも直していって、できればMTOS4.2xに移行していきたいな、と。。。この1年で、MovableTypeはver.4.2xまでバージョンアップしたし、MooToolsは最近1.2.1にやはりバージョンアップ。 MooToolsは業務でも常に接しているので、ネタはあるし技術ノウハウもかなり溜まってます。でも一方のMovableTypeの方は、実質MT4.01（今日時点でこのブログのMTのバージョン）を少しかじった程度で基本知識はMT3.3x止まり。ただ、これから業務でMT4.22を触るので、MovableTypeの方も少しずつ時流に追いつけるかなー、と。あと、ここだけの話（になるのか？）、会社の方で技術ブログを立ち上げる話も出ていたんです。そうなったらそちらに移行するかも、という構想もあったのですが、話が進まないまま1年が経過しようとしているので、待つのはやめて行動を起こさないと、と思ったわけでして。ということで、細々とした更新を続けていくことになると思われますが、これからもよろしくお願いします。

リニューアル（ほぼ）完了

2007-12-02T20:22:43Z

ブログをMT4化しました（やっとこさ）。取り敢えずきちんと動作しているはずです。デザインも変更しました。今まで小粋空間テンプレートのMT3.2用をカスタマイズして使用していましたが、MT4用のものに差し替え、さらに少しカスタマイズして使用しています。ただまだちょっと完全ではなく、一部のページが旧テンプレートで表示されてしまいます……。少しずつ直していきますので、長い目(——_——)で見てやってください。他にも、何か動作がおかしいところとかありましたらご指摘ください。

JavaScript-XPathのMooTools用プラグインを作成

2007-11-29T13:42:34Z

Prototype.js で XPath を手軽に扱うためのプラグイン XPath for Prototype というものが公開されています。作者の amachang さんのブログの、プラグイン公開を紹介する記事に、「他のライブラリのプラグインに関して」という見出しでこんなことが……。

もし
誰か書いてくれる人がいればとてもありがたいなあ。。。とか思っています。
いませんよねいませんよね＞＜？

面白そうなので、書いちゃいました(^-^) XPath for Prototype の MooTools 版、名付けて「XPath for MooTools」（まんま）。 【※2008/06/12 ver.0.2 にバージョンアップ】

.jsファイル本体

以下よりダウンロードしてください。 XPath for MooTools 0.2 ※2008/06/10に正式公開されたMooTools v.1.2に対応しました。従来のバージョン(v.0.1)はMooTools1.2には対応していません。MooToolsをバージョンアップする際は XPath for MooTools も v.0.2 にバージョンアップをお願いします。 ※ XPath for Prototype と比較すると分かると思いますが、ほとんどソースをそのまま流用させていただいています。 MooToolsはProtptype.jsをお手本に開発されたものなので、仕様もコンセプトもとてもよく似ているのです。

動作に必要なモノ

MooTools v1.x
※~~MooTools v1.2βでは動作確認を行っていません。多分 compatible オプション付きでダウンロードしたモノでないと動かないと思います。~~2008/06/10に正式公開された新バージョンのMooTools v.1.2に対応しました。従来どおり MooTools v.1.11 にも対応しています。
JavaScript-XPath
※XPathをネイティブでサポートしていないブラウザのために必要です。

使用方法

MooToolsのJavaScriptファイルを読み込みます。
JavaScript-XPathのJavaScriptファイルを読み込みます。
XPath for MooToolsのJavaScriptファイルを読み込みます。
XPathで楽しんでください！

※ 本家サイトの真似っこです(^-^;)

簡単なサンプル

こちらも XPath for Prototype のサンプルをベースにしています。 MooTools用にカスタマイズした部分に対する動きのサンプルも追加しています。

<html>
 <head><title>Hello, XPath!</title>
  
  <!-- import MooTools -->
  <script type="text/javascript" src="mootools.js"></script>
  <!-- import JavaScript-XPath -->
  <script type="text/javascript" src="javascript-xpath.js"></script>
  <!-- import XPath for MooTools -->
  <script type="text/javascript" src="xpath4mootools.js"></script>
  
  <!-- use XPath -->
  <script type="text/javascript">
// <![CDATA[
window.addEvent('domready', function() {
  
  var li = $x('//ul/li[@title="xpath"]')[0];
  //li.setHTML('Enjoy ' + li.innerHTML + '!');  // <- for MooTools v.1.11
  li.set('html', 'Enjoy ' + li.innerHTML + '!');  // <- for MooTools v.1.2
  
//  alert($(document.body).xpath('ul/li[1]')[0].innerHTML);
  alert($(document.body).getElementByXPath('ul/li[1]').innerHTML);
//  alert(document.getElementsByXPath('//ul/li[1]')[0].innerHTML);
  alert(document.getElementByXPath('//ul/li[1]').innerHTML);
  
  // Demo of Original Feature for MooTools
  document.getElementsByXPath('//ul/li').addEvent('mouseenter', function (event) {
    event = new Event(event);
    event.target.setStyle('font-style', 'oblique');
  }).addEvent('mouseleave', function (event) {
    new Event(event).target.setStyle('font-style', 'normal');
  });
  
});
// ]]>
  </script>
  
 </head>
 <body>
  <h1>Hello, XPath!</h1>
  <ul>
   <li title="xpath">xpath</li>
   <li>dom core</li>
   <li>css selector</li>
  </ul>
 </body>
</html>

実際の動きを確認できます。→デモ

サポートブラウザ

MooToolsの動作する（サポートされている）全てのブラウザ：

IE 6.0以降
Safari 2.0以降
Firefox 2.0以降
Opera 9.0以降

XPath for Prototype との差異

XPath for MooTools は、XPath for Prototype をお手本に（てゆーかぶっちゃけほとんどソースを流用）しているので、XPath for Prototype (0.1.2) と互換性があります。以下に、MooTools用にカスタマイズされた追加機能を中心に、XPath for MooTools の機能を簡単に紹介します。（XPath for MooTools 固有の機能は強調表示しておきます。）

$x() 関数: 引数に XPath 表現（、取得開始位置、結果のソートを期待するかどうかの真偽値）を受け取ります。
戻り値は $$()関数と同じElements型になる（内部で$$()関数を呼んでいる）ため、複数要素への一括のスタイル設定・イベントハンドラ追加等が可能です。
document.getElementsByXPath() メソッド: 引数に XPath 表現（、取得開始位置、結果のソートを期待するかどうかの真偽値）を受け取ります。機能的には $x() 関数と全く同じです。
document.getElementByXPath() メソッド: 引数に XPath 表現（、取得開始位置、結果のソートを期待するかどうかの真偽値）を受け取ります。
戻り値は、要素が取得できた場合はその要素（複数存在する場合は最初の要素1つのみ）(Element型)、存在しなかった場合は null です。
初めから要素が一意に特定できることが分かっている XPath 表現を用いるときに有効です。
Element::xpath(), Element::getElementsByXpath() メソッド: 引数に XPath 表現（、結果のソートを期待するかどうかの真偽値）を受け取ります。
取得開始位置はその要素自身となります。
戻り値は $x() 関数や document.getElementsByXPath() メソッドと同様です。
Element::getElementByXPath() メソッド: 引数に XPath 表現（、結果のソートを期待するかどうかの真偽値）を受け取ります。
取得開始位置はその要素自身となります。
戻り値は document.getElementByXPath() メソッドと同様です。

※ getElementByXPath() メソッド（"Elements"じゃない方）は、最初に見つかった要素1つのみを返す getElement() というメソッドがMooToolsに用意されているので、そのコンセプトを受け継いで用意しました。

非対応ブラウザでMooToolsを完全に無効にする方法

2007-11-23T05:21:08Z

いきなり後ろ向きなエントリーでちょっと恐縮なのです(汗) 趣味の範囲を超えて『仕事』でMooToolsを使用していると、ブラウザの対応範囲の問題というモノには常に悩まされます。具体的には、一番困るのが「古いブラウザにも対応して欲しい」というモノ。それはなんとか説得できたとして、次に来るのが「じゃあ、せめて非対応ブラウザでエラーが出ないようにして欲しい」。そこで、非対応ブラウザでエラーが出ないようにするMooToolsの微カスタマイズをお教えします。と言っても、元のソースもロジックも触らず、ちょっとだけ書き加えるだけです。

0. MooToolsをダウンロード

まずは、MooToolsの準備。サイトから、download を選択し、必要なオプションを選択してダウンロードします。『Choose the Components you need』は、もちろん必要なモノだけでOKです。初めてでよく分からないという人は、全てにチェックを入れてしまえばOK。その際、下から順にチェックを入れると簡単です。コンポーネントの依存性がある場合、必要なコンポーネントにも自動的にチェックが入りますので。ここで、ポイントは『Choose compression type』オプション。クリックするとラジオボタン（のようにデザインされたオプション群）が表示されますが、一番上の「JavaScript Packer」を選択します（何もしていなければデフォルトで選択されていると思います）。これを選択する理由は、「後の作業が一番分かりやすいから」。以降、この「JavaScript Packer」オプションでダウンロードされたモノとして続けます。

0-1. MooTools1.2b1の場合

2007/11/22 現在、MooToolsの最新ベータ版 ver.1.2b1 が公開されています。そちらのダウンロードページを見ると、『Choose compression type』オプションにまだ「JavaScript Packer」が用意されていません。 1.2b1 でかつPackerで圧縮されたモノを使用したい場合は、ご自分でDean　Edwards Packerのサイトで圧縮してみてください。ただし自己責任でお願いします。

1. .jsファイルの編集

（「JavaScript Packer」オプションでダウンロードした場合、）.jsファイルをテキストエディタで開くと、中身はおおざっぱに以下のようになっています。

 1: //MooTools, My Object Oriented Javascript Tools. Copyright (c) 2006-2007 Valerio Proietti, <http://mad4milk.net>, MIT Style License.
 2: 
 3: eval(function(p,a,c,k,e,d){e=function(c){return(c<a?'':e(parseInt(c/a)))+((c=c%a)>35?String.fromCharCode(c+29):c.toString(36))};...（長いので以下省略）

1行目はライセンス表示、2行目は空行、3行目は、MooToolsのすべての（選択された）コンポーネントのコードを圧縮した長い1行（eval()1文）になっています。この3行目の前と、３行目の後（＝ファイルの最後尾）に、それぞれ以下の内容を挿入します。

（3行目の前）

if((window.ActiveXObject)||(document.childNodes&&!document.all&&!navigator.taintEnabled)||(document.getBoxObjectFor!=null)||window.opera)/*@cc_on @if (@_win32 && @_jscript_version > 5.5) @*/

（ファイル最後尾）

//@end

つまり全体として、以下のようになります。

 1: //MooTools, My Object Oriented Javascript Tools. Copyright (c) 2006-2007 Valerio Proietti, <http://mad4milk.net>, MIT Style License.
 2: 
 3: if((window.ActiveXObject)||(document.childNodes&&!document.all&&!navigator.taintEnabled)||(document.getBoxObjectFor!=null)||window.opera)/*@cc_on @if (@_win32 && @_jscript_version > 5.5) @*/
 4: eval(function(p,a,c,k,e,d){e=function(c){return(c<a?'':e(parseInt(c/a)))+((c=c%a)>35?String.fromCharCode(c+29):c.toString(36))};...（長いので以下省略）
 5: //@end

これで終わりです。 MooTools非対応ブラウザでは、MooToolsは一切機能しません。この.jsファイルを使用すればOK、というワケです。

2. 非対応ブラウザでエラーを出さないスクリプト記述

上記のように加工した.jsファイルを使用すると、MooToolsを使用している前提で記述したスクリプトは、そのままだと非対応ブラウザだとエラーになってしまいます。（対応ブラウザなら問題ありません。）そこで、エラーを出さないようにするためにもう一工夫。 MooToolsを使用したい箇所を、以下のようなif文ブロックで括ります。

if (window.MooTools) {
    // MooToolsの機能を利用したスクリプトの記述
}

これは、MooToolsが有効ならば、グローバルな変数（≒window オブジェクトに設定されたプロパティ）にMooToolsというオブジェクトが設定されるからです。それが有効かどうかで、MooToolsが使えるかどうかを判別する、と言うわけです。

3. おまけ：技術情報

念のため、.jsファイル内に追記した記述がどのような意味なのかを簡単に解説。これは実は、MooTools(v1.1x)内のブラウザ判別ルーチンをほぼそのまま拝借しているだけです。興味のない方は読み飛ばしてください。 3行目のifの条件節は、「||」（論理和）で4つに別れます。最初が「IEかどうか」、2番目が「Safari（およびそれと同じWebKitを利用したブラウザ）かどうか」、3番目が「Firefox、Netscape等のGeckoエンジンを利用したブラウザかどうか」、4番目は「Operaかどうか」（まんま）です。 2番目の「WebKitかどうか」についてのみ詳細。その中が更に「&&」で3つに別れます。最初は「document.childNodes」が有効か（＝DOMが有効か）。これはほとんどのモダンブラウザなら有効です。一つ飛ばして3番目は、「navigator.taintEnabled が無効か」。 navigator.taintEnabled() というのは、「ユーザーに非通知でデータ送信が可能かどうか（データテイント機能の使用有無）を返すメソッド」です。「何それ？」て思われた方、ご安心ください。Netscape Navigator 3.x の時代の、古い古ーい仕様で、データテイント機能は現在使われておりません。多くのブラウザは、ただfalseを返すだけです。ただしSafari（WebKit）では、このメソッドそのものを定義していません。よって「!navigator.taintEnabled が true」＝「navigator.taintEnabled()が定義されていない」＝「Safari(WebKit)」という判別になるのです。じゃぁ2番目の「!document.all」は何なのか、というと。分かる方は分かると思いますが、「document.all」はIE固有のプロパティです。つまりこれはIEを除外するための記述です。（実際にはOperaも除外されてしまいますけれど）。なぜこれが必要なのかというと、どうやらIEでは、後ろに「()」をつけない「navigator.taintEnabled」を記述すると「オブジェクトまたはプロパティは存在しません」というエラーになってしまうようなのです。それを避けるための記述、ということですね。ただその前に「window.ActiveXObject」でIEかどうかは判別できているはずなので、やっぱりここでは要らないような気もしますけれど、一応、念のため付加してあります。 ifの条件節の後に続くコメントは、IE固有の「条件付きコンパイル」の記述です。そういう前提で眺めてみれば大体分かると思いますので、さらっと。ここでは、「WindowsでかつIE5.5より上のバージョン（＝WinIE6以上）」を判定しています。つまりWinIE5.5以下やmacIEを排除しています。ちなみにファイル最後尾に追記した「//@end」は、この条件付きコンパイル内の「@if」に対応する「if文（ブロック）の終わり」を表しています。

4. 応用・発展性

今回は、私が実際に仕事で（必要に迫られて）書いたものですが、同じような記述を応用すれば、MooTools以外のJavaScriptライブラリ使用時にも流用・転用できると思います。またMooToolsでも、理由があってPacker圧縮したものを使用できない（あるいはPackerが信用できない）という場合でも、ちょっと書き方を変えれば利用できるはずです。例えば、追記する記述中の、3行目の最後尾（条件付きコンパイルコメントの終わりの「*/」の後）に「{」を、最終行の「//@end」の前に「}」を付ける↓

（3行目の前）

if((window.ActiveXObject)||(document.childNodes&&!document.all&&!navigator.taintEnabled)||(document.getBoxObjectFor!=null)||window.opera)/*@cc_on @if (@_win32 && @_jscript_version > 5.5) @*/{

（ファイル最後尾）

}//@end

これだけで、他の多くのパターン（特にPackerを使用できない/したくない場合）に応用できるはずです。（ただし実験していないので、何か問題が起きても私は保証できかねますm(_ _)m）

そろそろ……。

2007-11-22T13:58:07Z

3ヶ月以上更新してませんでした。仕事忙しくて、MT4全然さわれなくて。この3連休をきっかけに、少しずつ動き出します。キーワードは2つ。『MT4化』と、『ダブルMT化』まずは、『MT4化』。裏では準備中です。余力があればデザインも少し触りたい。そして、『ダブルMT化』。つまり、サイトの方向性変更を検討中。 Movable Type とともに、MooToolsを中心とした JavaScript の話題をどんどん盛り込んで、半分は JavaScript サイトにしようか、と考えているわけです。ぶっちゃけ、今MovableType全然触っていない代わりにJavaScriptバリバリの仕事をしているので。で、MovableTypeもMooToolsも、頭文字を取ると"MT"なので『ダブルMT』、と。まずは、明日辺りに1件、MooToolsの話題を一つ振る予定です。

拙作プラグイン MovableType4 （随時）正式対応（中）

2007-08-18T14:04:40Z

やはりちょっと出遅れましたけれど。 MovableType 4.0 が正式公開されました。これに伴い、拙作プラグインのMT4.0正式対応版を順次公開していきます。対応状況は、このエントリーで随時紹介していきます。

一覧

プラグイン	対応	備考
DateSlashedFilter	○	非推奨
MTSpan	◎	2007/08/15付で正式対応
AutoIncrementalVar	◎	2007/08/18付で正式対応
CatSort	○
DateLangX	◎	MT4用を別アーカイブで提供(2008/12/02)
SbCode	△	一部機能が動作せず
MTVoid	◎	2007/08/15付で公開
PHPize プロジェクトによる各種PHP版プラグイン	×	ファイルを編集すれば動作

※【2008/12/02】 DateLangX MT4.x対応版公開に伴い一部追記・修正。

DateSlashedFilterについて

このプラグインは、個人的な需要とプラグイン作成の練習のために制作したモノです。「日付の表記を'/'区切りにする」という目的のためには、拙作の「DateLangX」プラグインを使用することをオススメします。（ただし、DateLangX は2007/08/18時点ではまだMT4には正式対応していません。）

DateLangXについて

メインの機能である、「ブログの基本設定の『日付表示用の言語』に『日付 '/' 区切り』の項目を追加」が、2007/08/18現在動作しません。（近日中にMT4対応版を公開する予定です。）別扱いでMT4対応版を公開しました。以下を参照してください。『日付の言語』の設定を拡張！ - DateLangX プラグイン for MT4 なお、ドキュメント化されていない機能ですが、日付を表示する各種テンプレートタグの属性（修正子）として、language="ja_sl" もしくは language="en_sl" と指定すれば、日付がスラッシュ区切りで表示されます。例：

<$MTDate><br />
<$MTDate language="ja_sl">

↓

2007年06月10日 09:20
2007/06/10 09:20

SbCodeについて

※2007/08/18時点では、MT4.0に正式対応しておりません。（ただし、とりあえずダイナミック環境以外では正常に動作します。またダイナミック・パブリッシングでも、.phpファイルを小文字化すればとりあえず動作します。） MT4の標準テンプレートは、かなり細かくモジュール分割がされています。そのおかげで、MT4の標準テンプレートに <$SbCode$> タグを埋め込む場合、編集するテンプレートは1つだけ（コメントフォームモジュール）で済みます。各ブログの管理画面から、デザイン → テンプレート → テンプレートモジュール → Comment Form と進んでください。表示されたテンプレートソース中に、今までと同様に「<input type="hidden" name="entry_id" value="<$MTEntryID$>" />」という記述がありますので、その直後に記述すればOKです。例：

 :
<input type="hidden" name="static" value="1" />
<input type="hidden" name="entry_id" value="<$MTEntryID$>" />
<$MTSbCode$>
 :

PHPize プロジェクトによる各種PHP版プラグインについて

近日中にMT4正式対応版を公開したいと思います。（とりあえず、.phpファイルの小文字化を実施すれば、現在公開しているものでも動作します。）

評価だけして中身を出力しない - MTVoid

2007-08-15T00:54:05Z

MTVoid 0.1 を公開します。 <MTVoid> というコンテンツタグを提供します。内容は評価するけれども、実際には何も出力しない、という動作をします。簡単な使用例： <MTVoid><$MTInclude identifier="styles"$></MTVoid> ↓ （MTIncludeの処理は行われますが、その内容は出力されません。）

動作環境

Movable Type（以下、MTと略記）ver.3.x、ver.4 以降。

ダウンロード

(どちらかを選択してください。内容は同じです。)

MTVoid プラグイン本体

MTVoid.zip[1,528 Bytes]
MTVoid.tar.gz[666 Bytes]

MTVoid プラグイン MT3ダイナミックパブリッシング対応差分

MTVoid_php_MT3.zip[351 Bytes]
MTVoid_php_MT3.tar.gz[194 Bytes]

インストール

MT3, MT4 共通

プラグイン本体のアーカイブをダウンロードしてください。
ダウンロードしたファイルを解凍してください。
解凍ソフトに「ディレクトリ構造を**」というオプションがある場合は、「ディレクトリ構造を有効（再現、等）」にして解凍すると、以下のようなディレクトリ構造が生成されます：
```
┗[MTVoid]
 ┣MTVoid.pl
 ┗[php]
  ┗block.mtvoid.php
```
MTVoid フォルダごと [MT]/plugins/ フォルダにコピー（アップロード）してください。

MT3.x でダイナミックパブリッシングをご使用の場合

以降の操作は、MT4では不要です。

MT3ダイナミックパブリッシング対応差分のアーカイブをダウンロードしてください。
ダウンロードしたファイルを解凍してください。
解凍すると、ただ1つのファイル block.MTVoid.php が生成されます。
解凍して得られたファイルを [MT]/php/plugins/ フォルダにコピー（アップロード）してください。

使い方

このプラグインが提供するのは、一つのコンテンツタグです。

<MTVoid>: 非出力タグ。
内容（コンテンツ）を評価しますが、その結果を（と言いますか何も）出力しません。

使用例

（前述の「簡単な使用例」を参照してください。）

MTIgnore との違い

括った範囲を出力しないタグとしては、MT標準（MT3.3x以降）で <MTIgnore> というタグが存在します。これは、その中身（コンテンツ）をまったく評価しません。文字通り『無視』するタグです。例えば、

<MTIgnore>
<$MTSetVar name="hoge" value="tara"$>
<$MTGetVar name="hoge"$>
</MTIgnore>

とすると、何も出力されない代わりに、MTSetVarが評価されないので、変数「hoge」には何も代入されません。つまり、他の場所で <$MTGetVar name="hoge"$> を記述しても「tara」とは出力されません（エラーになる可能性もあります）。これを

<MTVoid>
<$MTSetVar name="hoge" value="tara"$>
<$MTGetVar name="hoge"$>
</MTVoid>

と置き換えると、やはり何も出力されませんが、内容は評価されているので、他の場所で <$MTGetVar name="hoge"$> と記述するときちんと「tara」と出力されます。

MTSetVarBlock との違い

内容を評価だけして出力しない方法としては、標準タグを使用する方法としては MTSetVarBlock を利用するものがあります。先ほどの例の場合、

<MTSetVarBlock name="dummy">
<$MTSetVar name="hoge" value="tara"$>
<$MTGetVar name="hoge"$>
</MTSetVarBlock>

このようにしても、内容を評価だけしてその結果を出力しない、という目的は達成できます。ただしこの方法には、以下の問題点が存在します：

MTSetVarBlockに使用する変数名（この例の場合 dummy）は他で使われていないものにする必要がある
出力されないだけでその変数（で参照されるサーバのメモリ領域）にデータが残るので、微々たる物ではあれどサーバのメモリを一時的に圧迫する

MTVoid は、評価した内容は出力されないだけでなく、メモリ上にも残りません。また、変数名を心配する必要もまったくないので、よりスマートな解決策となります。

免責事項

継続的な開発をご支援くださる方は、よろしければドネーションをお願いいたします。

PayPal によるドネーション

おまけ

姉妹プラグインの MTSpan（評価した内容をそのまま出力するプラグイン）もヨロシク。

ダイナミック・パブリッシング対応プラグインの MT4 における仕様変更について

2007-06-19T10:41:47Z

MT4ベータが発表・公開されて、拙作のプラグインの動作確認をしていたのですが、一つ大きな問題を発見してしまいました。ダイナミック・パブリッシング対応のPHP版プラグインにおいて、以下のような問題が発生したのです。 ウチでは問題なく動くのに、ほかの環境ではまったく動作しない！ この現象について、原因と対処法が判明しましたので報告します。一言で言えば、『テンプレート・タグが大文字小文字を区別しなくなったことによる弊害』。

MT4におけるテンプレートタグの仕様変更

MT4では、テンプレートタグの記述に、大きくて小さな(?)仕様変更があります。それは、大まかに言うと以下の2点。

大文字・小文字を区別しなくなった
<mt:hogehoge> のようなxmlのネームスペースに倣った記述方法がサポートされた

前者は、たとえば <$MTEntryID$> を <$MTEntryId$> 等、今まで大文字小文字を間違えて記述した場合に、エラーもしくは何も表示されない等正常な動作をしなかったものが、これからは問題がなくなる、ということです。 <MTENTRYID> とか <mteNTRYiD> のように大文字小文字をむちゃくちゃにしても、綴りさえあっていれば問題なく動作します。後者は、これに加えて <mt:entryid> のような記述方法も許される、ということです。ただしこれは、 <mtentryid> と ":" を記述しない場合とまったく同じ意味になります。また ":" は "mt" の後のみ許されます。

テンプレート・タグを提供するプラグインの記述方法

では、プラグインの記述方法に変更が加わるのか、というと。スタティック環境に関する限り、変更は不要です。 MT4のFAQにも、「ユーザ・インタフェースを表示変更するようないくつかのプラグインを除けば、ほとんどのプラグインは後方互換性がある」とあります。（参照：http://www.movabletype.com/mt4/mt4_answers.html#backwards-compat）さらに、今までのプラグインとは別の「機能追加」の方法(snipetts)もあるようです。けれどもそれはまた別の話、いつかまた別のときに。とにかく実際、「ユーザ・インタフェースの変更を伴わない（＝BigPAPIやTransformer機能を利用していない）プラグイン」は、基本的には一切記述を修正することなく今までどおり動作するようになっている模様です。ですが。これはあくまでスタティックの話。ダイナミック・パブリッシングにおいては、プラグインの記述に若干の手直しが必要になります。具体的には、以下のような手直しが必要です：

ファイル名をすべて小文字にする(*1)
オリジナル・タグの機能を記述した関数名もすべて小文字にする
その他、プリセット、オリジナル問わずテンプレート・タグ名を記述している箇所があればすべて小文字にする

(*1)オリジナル・タグを提供するファイル（block.mtxxxx.php もしくは function.mtxxxx.php）のみ対象。これは、MT4でタグ名の大文字・小文字を区別しなくなった代わりに、ダイナミック・パブリッシング環境では内部的にはテンプレートタグをすべて小文字で管理しているためです。従来は、たとえば <$MTIncrementVar$> というタグを定義するために、 function.MTIncrementVar.php ファイルに function smarty_function_MTIncrementVar($args, &$ctx) という関数を定義する、みたいに大文字小文字の区別に合わせてそのとおりに記述する必要がありました。それを今度は、すべて小文字にしなければならない（function.mtincrementvar.php ファイルに function smarty_function_mtincrementvar($args, &$ctx) ）、というわけです。プラグイン作成側としては、ちょっとだけ面倒です。

それでも一部の環境で問題なく動いてしまう理由

しかしながら、冒頭に述べたように、私のテスト環境では、上記の修正を施すことなくPHP版のプラグインも正常に動作していました。これは、以下の2つの要因が重なって引き起こされていました。

サーバのファイルシステムが大文字・小文字を区別しないものであった
PHPの関数名はそもそも大文字・小文字が区別されない(*2)

(*2)少なくとも私のテストした環境のPHP(ver 4.4.1, 5.0.5)においては。前者の「ファイルシステムが大文字・小文字を区別しない」というのは、簡単に言えば「ABC.txt というファイルが存在するときに、"abc.txt" というファイルを開こうとすると、そのファイルが存在しなくてもエラーにならず、ABC.txt が開けてしまう」という現象が起きる、ということ。 Windowsで使用されている FAT32 や NTFS(*3)、Mac OS の標準ファイルシステムである HFS や HFS+ がこれにあたります。Mac OS X でも UFS というファイルシステムを採用したり、また Linux でよく使用される ext3 や、その他のUnix系OSで使用される各種ファイルシステムでは、大文字と小文字は厳密に区別されます。私のテスト環境は Mac OS X で、ファイルシステムが HFS+ だったので、この「ファイルシステムが大文字・小文字を区別しない」に該当したのです。 (*3)NTFS自体は大文字・小文字を区別するが、同じディレクトリ（フォルダ）にファイル名の大文字・小文字が違うだけのファイルを作成できない。また上に述べた「"abc.txt"というファイルを開こうとすると ABC.txt が開かれる」という現象は発生する。またPHPは、関数名およびクラス名において、大文字・小文字は区別されないようです。ドキュメントには「識別子は大文字・小文字が区別される」とありますが、それが適用されるのは変数名や定数名だけのようです（定数名はオプションで大文字・小文字を区別しないようにもできるそうです）。よって、関数名に大文字が混じっていても、すべて小文字の関数名で呼び出せばきちんと呼び出せてしまう、というわけです。これらの原因により、正常に読み込まれるはずのないプラグイン記述ファイルがきちんと読み込まれ、テンプレートタグがきちんと登録されて、結果としてきちんと動作してしまった、というわけです。

仕様変更だからです。←結論

（↑タイトルに深い意味はありません(汗)） PHP版プラグインを作成する際は、MT3以前用の「ファイル名・関数名の（タグ名にあたる部分を）大文字・小文字をそろえたファイル」と、MT4以降用の「ファイル名・関数名をすべて小文字にしたファイル」の2種類を用意しなければダメなようです。二度手間です。くぅ。今までどおりが良いのです。←ワガママ？

拙作プラグインの MovableType4β 対応状況

2007-06-10T00:15:41Z

出遅れましたけれど。改めて。 MovableType 4β が公開されました。気になる新機能やトピックスは、既に色々な方が記事にされているので、そちらにお譲りするとして。拙作のMTプラグインを、MT4βで動作するか検証してみました。その結果を報告します。【※2007/08/18 記事一部変更】

DateSlashedFilter

問題なく動作します。このプラグインは、日本語で表記された日付形式「○○○○年○○月○○日」をスラッシュ区切りの「○○○○/○○/○○」に変換するグローバルフィルターを提供するモノです。グローバルフィルター（グローバル・タグ・アトリビュート）に関してはMT4で仕様の変更はないようなので、グローバルフィルターを提供する他のプラグインも同様に、MT3用のものが問題なくそのまま使用できると思われます。ちなみに。このプラグインは、個人的な需要とプラグイン作成の練習のために制作したモノです。「日付の表記を'/'区切りにする」という目的のためには、拙作の「DateLangX」プラグインを使用することをオススメします。

MTSpan

問題なく動作します。こういった、MTの内部に踏み込まない単純なプラグインは、MT4でも問題なく使用できる模様です。

AutoIncrementalVar

スタティック環境においては問題なく動作することを確認しました。このプラグインは、<$MTSetVar$>/<$MTGetVar$>と互換性を持たせて設計していますが、MT4でも大きな仕様変更はない模様で、連携も今まで通り問題ない模様です。またこのプラグインは、ダイナミックパブリッシング対応のPHP版を同梱していますが、MT4のダイナミックパブリッシングもMT3と大きな仕様変更はない模様で、コチラも問題ない模様です。ダイナミック・パブリッシングにおいては、一部の環境を除き正常に動作しません。これは、MT4のダイナミック・パブリッシングにおいてプラグインの記述方法に若干の仕様変更がなされたためです。当方のテスト環境ではその影響を受けなかったので問題なく動作してしまったため、初め『問題ない』と報告してしまいました。申し訳ありません。詳細は、改めて別のエントリーで解説したいと思います。

CatSort

問題なく動作することを確認しました。 MT3.3以降のみに対応しているソートメソッドも、問題なく動作します。またプラグイン一覧表示画面の日本語ローカライズも問題ありません。

DateLangX

一部機能が正常に動作しません。メインの機能である、「ブログの基本設定の『日付表示用の言語』に『日付 '/' 区切り』の項目を追加」は、現在のところ動作しません。これは、2つの原因があります。

管理画面を編集するプラグイン(Transformerプラグイン)の書き方が仕様変更された。
管理画面そのものも大幅に変更された。

これらに対応するようプラグインを修正すれば、メイン機能が正常に動作することを確認済みです。（近日中にMT4対応評価版を公開する予定です。）またドキュメント化されていない機能ですが、日付を表示する各種テンプレートタグの属性として、language="ja_sl" もしくは language="en_sl" と指定すれば、日付がスラッシュ区切りで表示されます。これは、MT3.x、MT4ともに動作します。例：

<$MTDate><br />
<$MTDate language="ja_sl">

↓

2007年06月10日 09:20
2007/06/10 09:20

SbCode

概ね問題なく動作する模様です。 MT4からは、コメントの認証方法に仕様変更が見られます。具体的には、今までは認証サービスとして Typekey 認証のみが使用できましたが、MT4では以下のようにバリエーションが増えています。

Anonymous Comments（従来の非認証者のコメント）
Movable Type Native（MTに登録（作成）したユーザ）
OpenID
LiveJournal
Vox
TypeKey（従来の TypeKey 認証）

SbCode プラグインでは、TypeKey 認証者コメントの場合はハッシュを評価せずにコメントを許可するように設計していましたが、そのままのロジックで他の認証方法で認証されたコメントユーザもハッシュを評価せずにコメントが許可される模様です。ただし、検証したのは "Movable Type Native" のみです（2007/06/10 現在）。他の認証サービスは未検証です（サービスそのものが未経験）。引き続き調査いたします。なお、MT4の標準テンプレートは、かなり細かくモジュール分割がされています。そのおかげで、MT4の標準テンプレートに <$SbCode$> タグを埋め込む場合、編集するテンプレートは1つだけ（コメントフォームモジュール）で済みます。各ブログの管理画面から、 Design → Templates → Modules → Comment Form と進んでください。表示されたテンプレートソース中に、今までと同様に「<input type="hidden" name="entry_id" value="<$MTEntryID$>" />」という記述がありますので、その直後に記述すればOKです。例：

 :
<input type="hidden" name="static" value="1" />
<input type="hidden" name="entry_id" value="<$MTEntryID$>" />
<$MTSbCode$>
 :

PHPize プロジェクトによる各種PHP版プラグイン

~~概ね問題なく動作する模様です。~~ これまでPHP化したプラグインはあまりMTの内部に踏み込んだモノではなく、またダイナミックパブリッシングそのものも大幅な仕様変更はない模様なので、各プラグインも問題なく動作する模様です。より詳細が確認できましたら追って報告します。一部の環境を除き正常に動作しません。これは、MT4のダイナミック・パブリッシングにおいてプラグインの記述方法に若干の仕様変更がなされたためです。当方のテスト環境ではその影響を受けなかったので問題なく動作してしまったため、初め『問題ない』と報告してしまいました。申し訳ありません。詳細は、改めて別のエントリーで解説したいと思います。

免責事項

この調査は、~~2007/06/05 に一般公開された Mt4β1~~2007/06/12 に公開された Mt4β2 を元に実施しております。今後発表されるかもしれないβ2β3以降や、正式版では、仕様が変更される可能性もあり、プラグインの動作状況も変動する可能性があります。その都度、できる限り検証し報告する予定です。【2007/08/18】MT4.0 正式版が公開されたので、このエントリーでの報告は終了します。以降は、拙作プラグイン MovableType4 （随時）正式対応（中）にて、対応状況および正式対応版の公開を報告していきます。（このエントリーへのコメントおよびトラックバックの受付は終了しました。）

Ajaxライブラリ MooTools の紹介

2007-06-05T14:54:56Z

今、仕事の合間に色々なAjax/JavaScriptライブラリを触っています。そんな中で、個人的に注目したのが、『MooTools』。エフェクト系のライブラリに分類されがちですが、DOM操作やリモート操作（XMLHttpRequestを使用したサーバとのやりとり）、Safariを初めとするメジャーなモダンブラウザへの対応（クロスブラウザ対応）など、コアな部分もしっかりしており、Prototype.js(+Script.aculo.us)の代替としても充分かそれ以上のモノを備えています。主な特徴を挙げるとすれば、以下の通り：

軽量・高速
Safariを筆頭に、IE6,7、Firefox、Opera等でテスト済み
$()関数、$$()関数等、prototype.jsとの互換性があり、移行が容易
オブジェクト指向で、記述が直感的
デモが豊富、ドキュメントも充実、できること・やりたいことがすぐ分かる！

以下に、一番人気と歌われるAjax基本ライブラリ Prototype.js との比較をしてみます。

Prototype.js との共通点～基本的な記述方式～

MooToolsは、元々 moo.fx というエフェクトライブラリから先に誕生したモノ。このmoo.fxは、Prototype.js と組み合わせて使用できるようになっているそうです。その後、Ajax関連のコアな部分や、その他の基本ライブラリも含めて、ライブラリ全体としてMooToolsという名称で現在に至っている模様です。おそらくそう言う経緯があってか、MooToolsのコアな部分は、PrototType.jsのそれに非常によく似ています。例えば、DOM要素を抜き出す $() 関数や $$() 関数、配列を生成する $A() 関数や配列の拡張である .each(function(item,idx){～}) メソッド等は、Prototype.js 用に書いたコードがそのままMooToolsでも使用できます。一部、Prototype.js にはあって(ver.アップで追加されて)MooToolsにはないメソッドもあります。でも、Prototype.js が肥大化しAPIが煩雑になる傾向にあるのに対して、MooToolsは必要十分なメソッドに抑えて、しかもそのメソッドに使いやすい拡張や洗練された実装が見られるのです。（詳細は余裕があればまた改めてまとめてみようと思います。）

Prototype.js の拡張～$$()関数の戻り値～

Prototype.jsでは、$$()関数の戻り値は Element オブジェクトの配列です。よってその各要素に対して何か処理をする場合、例えば以下のように書く必要があります：

var elements = $$('myselector');
elements.each(function(el){
  el.setStyle('color', 'red');
});

このコードはMooToolsでもそのまま動作しますが、MooToolsではもっと簡潔に、以下のように書くこともできます：

var elements = $$('myselector');
elements.setStyle('color', 'red');

これは、$$()関数の戻り値がElementオブジェクトの配列ではなく、Elementsオブジェクトになっているからです。 Elementsオブジェクトは、内部にElementオブジェクトの配列を保持しています。またElementオブジェクトのメソッドを全て継承しており、それを内部の全てのElementオブジェクトに対して作用させるようになっています。このように、それが単一のElementか、複数のElementsかを意識する必要なく、同じ記述ができるようになっている、というわけです。

オブジェクト指向の作法に則ったAjax呼び出し

Ajaxの要、XMLHttpRequest（もしくはその代替）を利用したサーバとのやりとりの記述には、Prototype.js と MooTools とでは多少の違いが見られます。 Prototype.js では、Ajaxオブジェクトは他の実働クラスの親クラスおよび名前空間としての役割となっています。「実働クラス」というのは、例えばAjaxの一般的なやりとりをカプセル化する Ajax.Request オブジェクトなど、実際に処理をするオブジェクト（を定義するモノ）のことです。例えばこの Ajax.Request オブジェクトを使用した典型的な書式は、以下のようになります：

var myAjax = new Ajax.Request(
  url,
  {
    method: 'get',
    parameters: pars,
    onComplete: showResponse
  }
);

実はこの書き方、私は違和感があったんですね。 Java等のオブジェクト指向言語を勉強したり業務で使用したことのある人は、「コンストラクタで全ての処理を行っちゃダメ」と教わったり言われたことがあると思います。 "new"という命令（演算子）は、『あたらいいオブジェクトを生成する』という意味。でも中では、実際のリクエスト発行までもやっているわけです。つまり。こう考えてください。この部分を日本語に直すとこうなります。「新しい Ajax.Request オブジェクトを生成（リクエスト先は url、メソッドは GET、パラメータは pars、完了したら showResponse 関数を実行する）して、その内容を myAjax変数に格納する。」ね。どこにも「実際にリクエストを発行する」なんて書いてないでしょ？こういうのは、仕事でプログラムを書く人には「あまり良くない作法」として教えられるのです。それが、MooTools ではお行儀よく矯正されています。同じことを MooTools の書き方で書くと、以下のようになります。

var myAjax = new Ajax(
  url,
  {
    method: 'get',
    data: pars
  }
);
myAjax.request().chain(function(){showResponse(this)});

これを日本語的に読むと、こうなります。「新しい Ajax オブジェクトを生成（リクエスト先は url、メソッドは GET、パラメータは pars）して、その内容を myAjax変数に格納する。リクエストを発行して、完了したら続いて（chainして）showResponse 関数を実行する。」直感的でしょ？それに読んでみても過不足なく必要十分。ちなみにMooToolsでは、Ajaxオブジェクトそのものが、Ajax関連の操作をカプセル化する唯一のクラスになっています。そのプロパティやメソッドで、リクエストを発行したり、その結果を直接HTML上の要素に反映させたりします。このあたりは、Prototype.js から移行する際にはちょっと注意する必要があります。また、コールバック関数指定と chain() メソッドによる連続実行指定という差異、そこに渡される引数の違い等も注意が必要です。逆に Prototype.js を知らずに MooTools から始める場合には、あまり違和感なく入れると思います。（ただ、そもそも each() メソッド同様、引数に無名関数を渡すという手法の時点で JavaScript 特有の書式になるので、JavaScript になれていない人には最初は違和感があるかもですけれど。）

PHPizeプロジェクトについて

2007-05-10T14:56:39Z

本日(2007/05/10)付の小粋空間さんの記事（ダイナミック・パブリッシングで perl のプラグインを利用する）で、当サイトの「MTプラグイン PHPizeプロジェクト」がご紹介を受けました。（にわかにアクセスが増えてちょっとびっくりしました(笑)）ということで、その「MTプラグイン PHPizeプロジェクト」について、改めて説明いたします。極々簡単に言うとこれは、「既存のプラグインを勝手にPHP化（ダイナミック・パブリッシング対応に）する」というモノです。

PHPizeプロジェクトとは

Movable Type (以下、MT)には、ダイナミック・パブリッシングという機能があるのは、このサイトを見に来てくださっている方なら大体ご存知かと思います。また、MTはプラグインにより機能を拡張することができる、というのも周知のことと思われます。またそのプラグインは、少なからず、テンプレートを記述するのに便利なオリジナルのMTタグ（テンプレートタグ）を提供しています。ところが、この2つの事実はあまり密接にリンクしていません。プラグインで提供されるオリジナル・テンプレートタグの多くは、ダイナミック・パブリッシング対応にはなっていません。これは、プラグインそのもの（本体）はPerlで記述され、スタティック版のオリジナル・テンプレートタグもPerlで記述されるのに対し、ダイナミック・パブリッシング対応のテンプレートタグはPHPと、記述言語が異なることがその根底にあると思われます。だから、Perlでプラグインを記述するけれど、提供するテンプレートタグはスタティック専用、ダイナミック・パブリッシングでは使えません、となってしまう。でも、同じ機能を持つPHP版のテンプレートタグを用意さえすれば、同じテンプレートをスタティックからダイナミックに簡単に切り替えることもできるのです。『じゃ、ないものは自分で作っちゃえ。』そんな単純な発想から生まれた個人プロジェクト、それが、「MTプラグイン PHPizeプロジェクト」なのです。

今までの成果

これは論より証拠、ということで。 PHPizeしたプラグインは、このブログでタグに「PHPize」をつけた記事で公開しています。このタグでブログを検索すれば、これまでに作成（勝手にPHP化）したプラグインの一覧が出てきます。

今後の予定

現在業務多忙につき、PHPizeプロジェクトは小康状態（そもそもこのブログが非活性状態）ですが、今後も続けていく予定ではいます。今考えているPHPize対象プラグインは、以下の通りです（随時更新）：

MTCollate: 関連記事……MTCollateのススメ; 対応時期……未定

要望の受付

もし「このプラグイン（テンプレートタグ）をPHP化してほしい」という要望がありましたら、このエントリーへのコメントか、もしくはメールフォームよりメールにてお寄せください。ただし。完全に一個人がやっているプロジェクトなので、ご期待に添えない場合もあるかも知れません。その時はご容赦ください。

onkeypressをお行儀良くする追加スクリプト

2007-05-01T13:41:41Z

前エントリー（【提案】onkeypressの正しい併用の仕方！）からの続きです。ご用とお急ぎでない方は、前エントリーからお読みいただくと、今回このスクリプトを提供する経緯がお分かりになると思います。 onclickとonkeypressの両イベント属性を併用している場合に、onkeypressの挙動をお行儀よく修正する追加スクリプトを提供します。このスクリプトは、前エントリーで分類した、以下のパターンに対して有効に作用するモノです：

onclick と onkeypress が同時に指定され、その内容が同じの場合

またその時に、そのような箇所を以下のように修正します：

onkeypressイベントハンドラにフィルターをかける

概要

念のため、もう一度おさらいします。『onclick 属性を設定した場合は onkeypress 属性を同時に設定することがアクセシビリティ上好ましいとされています』という情報が出回っていますが、これを文字通りに受け取って、例えば↓

<a href="javascript:void(0);" onclick="clickAction();" onkeypress="clickAction();">Click Here!</a>

のように、onclickとonkeypressに全く同じモノを指定してしまうと、却ってキーボードユーザビリティが損なわれてしまうことがあります。（詳細は、前エントリー（【提案】onkeypressの正しい併用の仕方！）を参照してください。）今回提供するスクリプトは、このような状態に対して、上記のような記述はそのままで、onkeypressの挙動を上書きすることによりキーボードユーザビリティの回復を図る、というモノです。つまり！フリーのスクリプトで、上記のようにonclickとonkeypressが同時指定されてしまっているときに、その部分を触らずに、面倒なソースの修正など一切せずに、当サイトの提案する「正しい併用の仕方」が実現できる、というワケです！

スクリプト本体

以下からダウンロードしてください。

correctOnKeyPress.js[1,492 Bytes]

（リンクを右クリックし「名前を付けて保存」等で保存してください。）

スクリプトの使い方

ダウンロードしたスクリプトをお使いのWebサーバの適当な場所にコピー（アップロード）してください。
HTMLの最後の方、</body>の直前あたりに、以下のように記述してください：
```
     :
    <script type="text/javascript" src="/js/correctOnKeyPress.js"></script>
</body>
```
（ドキュメントルートの js フォルダにスクリプトをコピーした場合）

以上。これだけです。お使いの「onclickとonkeypressに同じモノを指定している」スクリプトで、キーボード操作が期待通りに動作する（[Enter]キー以外で変な動作にならない）ことをご確認ください。

技術情報

このスクリプトは、概ね以下のような処理をしています。

全てのHTML要素のうち、onkeypressとonclickが同時に指定されているモノを探す。
onclickとonkeypressに全く同じ指定がされているモノのみ抜き出す。
onkeypressイベントハンドラを上書きする：
1. キーコードが10,13([Enter]キー)および32(スペースキー)以外の場合は、元々指定されていたイベントハンドラを実行しない
2. キーコードが32(スペースキー)で、かつ対象となる要素がボタン要素(<input>, <button>)以外の場合は、元々指定されていたイベントハンドラを実行しない
3. 上記に引っかからなかった場合に、元のイベントハンドラを実行する

こうすることにより、ボタンなら[Enter]キーかスペースキー、それ以外なら[Enter]キーが押されたときにのみ、イベントが処理されるようになります。

お約束

多くの環境で充分な検証はしておりますが、もし不具合等ありましたらぜひともご報告をお願いします。

【提案】onkeypressの正しい併用の仕方！

2007-04-30T01:43:29Z

前エントリー（onkeypress、乱用禁止！）からの続きです。お暇なら、前エントリーからお読みください。 onkeypress イベント属性の正しい指定の仕方を提案します。主に『onclickと同時にonkeypressイベント属性を指定する場合の正しい指定の仕方』という視点での提案です。ざっくりとまとめると、対処法としては以下の3パターンがあります。

onkeypressは使わない！（onkeypressの指定を削除する）
onkeypressイベントハンドラにフィルターをかける
その他（個別の対応が必要）

【2007/05/02】追記。

まずは分類

現状はびこっている onkeypress の指定の仕方を分類してみました。それぞれにたいして、対処法が上述のA～Cのいずれに当てはまるかを後述します。

初めから onkeypress が単独で使用されている場合
onclick と onkeypress が同時に指定され、その内容が同じの場合
1. ボタン要素(<input type="button"～>、<button ～>)、およびアンカー要素(<a href="～"～>)の場合
2. それ以外の要素(<span>、<div>等)の場合
onclick と onkeypress が同時に指定され、その内容が異なる場合

初めから onkeypress が単独で使用されている場合

対処法: C. その他（個別の対応が必要）元々『onclick 属性を設定した場合は onkeypress 属性を同時に設定することがアクセシビリティ上好ましいとされています』という不確かな情報を元に両方設定している場合に対する対処法の提案なので、この場合は本来対象外です。ただ必要に応じて、onkeypress で指定しているスクリプトの内容について精査して、前回のエントリーで言及したような『元々のキーに与えられている機能が抑えられてしまったり、別の機能が与えられてしまったりして、結果的にユーザビリティが低下してしまう』といったことが起こっていないか検証する必要はあります。

onclick と onkeypress が同時に指定され、その内容が同じの場合

ボタン要素(<input type="button"～>、<button ～>)、およびアンカー要素(<a href="～"～>)の場合

対処法1: A. onkeypressは使わない！（onkeypressの指定を削除する）一般的なビジュアルブラウザ（ボタンをきちんとボタンの形で表示するブラウザ、要するにほとんどの方が日常使用しているWebブラウザ）では、ボタンの上にフォーカスがあるときに、[Enter]キー・[Return]キー・スペースキーのいずれかが押されると、そのボタンがクリックされたときと同じ動作をするようになっています。またアンカー（リンク）も、その上にフォーカスがあるときに[Enter]や[Return]を押すと、多くブラウザでやはりクリック時と同じ動作をします。つまり、これらの要素にはブラウザ本来の機能としてキーボードユーザビリティが提供されているのです。だから、onkeypress属性をわざわざ指定する必要はありません。 対処法2: B. onkeypressイベントハンドラにフィルターをかける「対処法1」では「不要」と書きましたが、ひょっとしたら、JavaScriptには対応しているけれど基本的なキーボードユーザビリティを提供していない（ボタン上で[Enter]キーを押しても何も動作しない）ブラウザがあるかも知れません。また、[Enter]キー押下などのキーボード操作では onclick イベントを拾ってくれないブラウザ、というのも存在するかも知れません。そういったものまで想定するのなら、onkeypress イベント属性の設定は必要です。ただし、そのまま onclick と同じモノを指定してはもちろんダメ。先述の『元々のキーに与えられている機能が抑えられてしまったり、別の機能が与えられてしまったりして、結果的にユーザビリティが低下してしまう』という現象が起きてしまいますので。具体的な対処法は、以下のそれ以外の要素(<span>、<div>等)の場合の対処法を参照してください。

それ以外の要素(<span>、<div>等)の場合

対処法: B. onkeypressイベントハンドラにフィルターをかけるこれらの要素では、[Enter]や[Return]キーが押されても同じ動作になるというキーボードユーザビリティが初めから提供されているとは限りません。というより、ブラウザの実装に依りますが、まずそのような機能は提供されていないと考えた方が良いと思います。 (Operaではそのような機能が実装されちゃってますが。) そこでこれらの要素には、抜本的な対策が必要となります。例えば、以下のようなソースを想定します：

<script type="text/javascript">
function clickAction() {
    alert('DUMMY!');
}
</script>
<a href="javascript:void(0);" onclick="clickAction();">Click Here!</a>

（説明のしやすさを考えてアンカー要素(<a>)にonclickを指定しました。）これは実際に表示すると↓こうなります。

Click Here!

「Click Here!」と書かれているリンクをクリックすると、ダイアログで「DUMMY!」と表示されます。 <a>のリンクになっているので、このままでも多くのブラウザでは、リンク上にフォーカスを持っていって[Enter]キーを押せば同じようにダイアログで「DUMMY!」と表示されるはずです。続いて、onkeypress で全く同じモノを指定してみましょう。

<script type="text/javascript">
function clickAction() {
    alert('DUMMY!');
}
</script>
<a href="javascript:void(0);" onclick="clickAction();" onkeypress="clickAction();">Click Here!</a>

表示は↓、見た目は同じです。

Click Here!

クリックしたときの動作も同じです。でも、キーを押したとき、特に[Enter]キー以外を押したときの動作に注意。例えば、[Tab]キーか、スペースキーを押してみましょう。少なくともいずれかの場合に、やはり「DUMMY!」というダイアログが表示されてしまったのではないでしょうか？これが、『元々のキーに別の機能が与えられてしまってユーザビリティが低下している状態』です。（[Tab]キーは「次のリンクに移る」、スペースキーは「画面下へスクロール」という機能が期待されるキーです。）ここからが本題。このonkeypressイベントに、フィルターをかけます。ここでいうフィルターとは、「どのキーが押されたかによって処理を分けること」という意味です。具体的には↓こうします。

<script type="text/javascript">
function keyPressFilter(evt) {
    var keyCode;
    if (evt) {
        keyCode = evt.keyCode;
    } else {
        keyCode = event.keyCode;
    }
    // ↓[Enter]キーが押されたかどうかの判定
    if (keyCode != 10 && keyCode != 13) {
        return true;
    } else {
        clickAction();
        return false;
    }
}
function clickAction() {
    alert('DUMMY!');
}
</script>
<a href="javascript:void(0);" onclick="clickAction();" onkeypress="return keyPressFilter(event);">Click Here!</a>

少々長くなってしまいました。でも見た目は↓やはり何ら変わりはありません。

Click Here!

クリックしたときの動作も同じです。そして、キーを押したときの動作はというと。リンク上にフォーカスがある状態で[Enter]以外のキーが押されても、ダイアログは出現せず、そのキー本来の機能が有効になっているのが確認できると思います。ポイントは、ソース中に「// ↓[Enter]キーが押されたかどうかの判定」と書かれている箇所。ここで、押されたキーがキーコードの10番もしくは13番（＝いずれかが[Enter]キー。通常13番）に該当するかどうかを判定しています。該当しなければ、イベント処理をスルー（return true;）し、該当すれば onclick のときと同じイベントハンドラを呼び出しています。これによって、[Enter]キーが押されたときだけ目的の処理が行われるようになりました。一応、念のため。なぜ[Enter]キーのときだけ、としたかというと。『リンクをクリックする』という操作に対応するキーボード操作として一番妥当なのが『[Enter]キーを押下する』だと思われるからです。これがボタンなら、つまり『ボタンをクリックする』なら、他に『スペースキーを押下する』も選択肢にくわえなければならないでしょう。スペースキーのキーコードは通常32番なので、先ほどの条件分岐を以下のようにする必要があります。

     :
    // ↓[Enter]キーもしくはスペースキーが押されたかどうかの判定
    if (keyCode != 10 && keyCode != 13 && keyCode != 32) {
     :

onclick と onkeypress が同時に指定され、その内容が異なる場合

対処法: C. その他（個別の対応が必要）この場合は、「onkeypress の場合は onclick とは別の動作をする」という指定か、初めから「特定のキーが押されたときにだけ onclick と同じ動作をする」という指定がされているものとおもわれます。そうならば、おそらく何の対処も要らないと思われます。一応、onkeypress で指定されているイベントハンドラの内部を検証する必要はあると思います。

まとめ

基本的には、「onclick 属性のしてある要素に onkeypress も指定する」という思想は、現状では妄信に近いものです。めんどくさければ「onclick を指定してあれば onkeypress は指定しない」のが一番です。onclick が指定されていれば、世の中のWebサイト閲覧者の9割は（例えキーボード操作を強いられようとも）そんなに困らないような作りになっていますから。つまりその方がよっぽど『高ユーザビリティを保てるようになっている』のですから。それでも、より高い操作性を求めたり、将来的なモノを見越したりして、「キーボード操作でもマウス操作と同じユーザビリティを提供しているんだということを、ソースに明確に記述することで示したい」という方は、ぜひこの記事を参考にしてください。また「現状、何も知らずに言われるがママに『onclickとonkeypressを併用』しちゃってるけれど、どうしたらよいでしょう？」という方には、現状を多少なりとも改善する方法、ただし今回のエントリーのようなめんどくさい記述ができる限り不要な解決方法を~~改めてご紹介（ご提供）する予定です~~次のエントリーでご紹介（ご提供）します。 ~~（少々お待ちを。。。）~~ →onkeypressをお行儀良くする追加スクリプト

onkeypress、乱用禁止！

2007-04-29T07:43:18Z

Webサイト構築やブログのカスタマイズをするにあたり、参考になるサイトを見ていると、よくこんな記述を見かけます。

onclick 属性を設定した場合は onkeypress 属性を同時に設定することがアクセシビリティ上好ましいとされています。

それがなぜそうであるのか、分かってやっていれば良いのですが、「～とされています」とだけ紹介してきちんと検証していない人、けっこういます。そもそもこの設定は、アクセシビリティよりもユーザビリティに関する提案です。しかも。「へーそうなのかー」と何も考えずにそれに倣って設定すると、却ってユーザビリティを悪くします！

論より証拠

まずは、こちらのサイトをご覧ください。 →使えない文字 HTMLで「そのままでは表示できない文字」の紹介と、それを表示する方法（＝文字参照）について解説しているサイトです。このサイト自体はとても有用なサイトで、初掲載からかなりの年月が経っている（ターゲットブラウザはIE6およびNN6、またホームページ自体は閉鎖されている模様）にもかかわらず現在でも十分通用する内容になっています。その内容に関しては今回の本題から外れるので、またの機会に。上記サイトの、後半過ぎあたりの「HTML 4 文字参照」という箇所をご覧ください。入力した文字が、数値文字参照もしくは文字実体参照に変換したり、逆に数値文字参照や文字実体参照を実際の文字に変換したりできるようになっています。（HTMLの文字参照以外に、CSS・JavaScriptの文字参照にも対応しています。）この、「HTML 4 文字参照」の入力テキストフィールドに適当な文字を入力して、[Tab]キーを数回押してください。一般的なブラウザなら、3～4回押すと「HTML 4 変換！」ボタンの上にフォーカスが移動します。（ここでボタンにフォーカスが移動しないブラウザは、この現象の対象外ですので、続きは読み飛ばしていただいても構いません。ただ、大事な話になるので、IE、Firefox、Opera 等の対象ブラウザでもう一度確認することをオススメします。）さて、この「HTML 4 変換！」ボタンの上にフォーカスがある状態で、もう一回、[Tab]キーを押してみてください。テキストフィールド内の文字が、勝手に変換されませんでしたか？ここで「えー、変換されないよ？」という方は、きっとWinIEをお使いですね。 Firefox や Opera といった『標準準拠ブラウザ』でもう一度見直してください。 ↑これらのブラウザでは、フォーカスが隣の「リセット」ボタンに移動するとともに、ボタンを押してもいないのにボタンを押したときの動作が引き起こされてしまっているのです。ちなみにその「リセット」ボタンにフォーカスがある状態でさらに[Tab]キーを押すと、入力文字がクリアされてしまいます。せっかく入力し、変換してくれた文字が、消えてしまうのです(泣) これが、「onkeypressを乱用」したことによる功罪の典型的な例です。つまり、この「HTML 4 変換！」ボタンや「リセット」ボタンに、onclickとともにonkeypressイベントが設定されているのです。その結果、標準的なブラウザでは、そのボタンにフォーカスがあるときに何かキーが押されたら、そのボタンをクリックしたときと同じ動作をしてしまうのです。ここで注意すべきは、「どんなキーが押されたにもかかわらず」、ということ。 [Tab]キーは、Webブラウザでは、リンクをたどったり、フォームの各要素（テキストフィールド、チェックボックス、ボタン等）を移動したりするのに利用することのできるキーです。これは標準的なユーザビリティです。一時的にマウスが使えない場合など、キーボードで全て操作したい場合などにとても有効です。逆に言えば、その機能が敢えて抑えられてしまったり、別の機能が与えられてしまうと、とても不便になります。ユーザに混乱を与える、つまり、ユーザビリティが低下してしまいます。スペースキーもそうですね。スペースキーは、フォーカスがボタンやラジオボタン、チェックボックス等の、文字入力以外のフォーム要素の上にあるときには、クリックと同じ動作になります。文字入力要素（テキストフィールド、パスワードフィールド、テキストエリア等）の中なら文字通りスペース文字の入力。それ以外の場所の場合は、一般的なブラウザではウィンドウの一画面分下スクロール（[PageDown]キーと同様の動作）に割り当てられています。（ちなみに[Shift]+スペースキーで一画面分上スクロール（＝[PageUp]）。また一部ブラウザでは日本語入力をOFFにしていないと有効になりません。）ところが。先ほどのサイトをOperaで見てみてください。先ほどと同じ「HTML 4 変換！」で、スペースキーを押してみてください。文字が変換されるとともに、画面が下にスクロールしてしまいます。しかも。ボタンが何度も押されたかのように、変換結果がおかしくなっています。これも、「onkeypress」の功罪です。ちなみに Opera には、標準機能としてのキーボード・ユーザビリティに独自の工夫が為されています。 [Shift]キーを押しながらカーソルキー（矢印キー）を押すと、その矢印の方向にある次に近いリンク（ボタンもしくはテキストフィールド）にフォーカスが移動するようになっています。また各アルファベットキーにも色々な機能が割り当てられています（zで前のページ、xで次のページ、aでリンクをたどる、sで<hn>要素をたどる、等）。 onkeypressはそれらのキー押下を拾ってしまうので、「aキーで次のリンクに飛びたいけれど、サイドメニューが展開/折りたたみして先に進めないー」なんてことも起こります。困ったモノです。どうしたらよいかというと、長くなってしまったので次のエントリーに続きます。 →【提案】onkeypressの正しい併用の仕方！

あんちもん2.Lab

『日付の言語』の設定を拡張！ - DateLangX プラグイン for MT4

ダウンロード

ver.0.1 [New!]

動作環境

インストール

機能 - 日付の言語の拡張

現在分かっている問題点

更新履歴

免責事項

丸1年ぶりの更新です。。。

リニューアル（ほぼ）完了

JavaScript-XPathのMooTools用プラグインを作成

.jsファイル本体

動作に必要なモノ

使用方法

簡単なサンプル

サポートブラウザ

XPath for Prototype との差異

非対応ブラウザでMooToolsを完全に無効にする方法

0. MooToolsをダウンロード

0-1. MooTools1.2b1の場合

1. .jsファイルの編集

2. 非対応ブラウザでエラーを出さないスクリプト記述

3. おまけ：技術情報

4. 応用・発展性

そろそろ……。

拙作プラグイン MovableType4 （随時）正式対応（中）

一覧

DateSlashedFilterについて

DateLangXについて

SbCodeについて

PHPize プロジェクトによる各種PHP版プラグインについて

評価だけして中身を出力しない - MTVoid

動作環境

ダウンロード

MTVoid プラグイン本体

MTVoid プラグイン MT3ダイナミックパブリッシング対応差分

インストール

MT3, MT4 共通

MT3.x でダイナミックパブリッシングをご使用の場合

使い方

使用例

MTIgnore との違い

MTSetVarBlock との違い

免責事項

おまけ

ダイナミック・パブリッシング対応プラグインの MT4 における仕様変更について

MT4におけるテンプレートタグの仕様変更

テンプレート・タグを提供するプラグインの記述方法

それでも一部の環境で問題なく動いてしまう理由

仕様変更だからです。←結論

拙作プラグインの MovableType4β 対応状況

DateSlashedFilter

MTSpan

AutoIncrementalVar

CatSort

DateLangX

SbCode

PHPize プロジェクトによる各種PHP版プラグイン

免責事項

Ajaxライブラリ MooTools の紹介

Prototype.js との共通点 ～基本的な記述方式～

Prototype.js の拡張 ～$$()関数の戻り値～

オブジェクト指向の作法に則ったAjax呼び出し

PHPizeプロジェクトについて

PHPizeプロジェクトとは

今までの成果

今後の予定

要望の受付

onkeypressをお行儀良くする追加スクリプト

概要

スクリプト本体

スクリプトの使い方

技術情報

お約束

【提案】onkeypressの正しい併用の仕方！

まずは分類

初めから onkeypress が単独で使用されている場合

onclick と onkeypress が同時に指定され、その内容が同じの場合

Prototype.js との共通点～基本的な記述方式～

Prototype.js の拡張～$$()関数の戻り値～