同じようなな単語にconfirmとかverifyという単語もあり、ネイティブでない我々には違いが分かりづらいのですね。結果が正しいかどうかを確認する。IT用語では、通信回線などで欠損があった場合に検算をして正しく伝送されてかを確かめるという使い方をします。こちらは、複数の意味があって、確認するという意味より、〈決心・意見などを〉強める,固める。承認とか追認なんて意味に近いイメージにとらえています。ユーザーが行おうとしていることを確認させるといった意味合いです。この聞きなれないvalidateですが、IT業界(もしかしたらWeb系のIT業界だけかもしれないけど)では、入力チェックという意味に捉えています。一般にWebアプリケーションが普及するまえには、プログラムはスタンドアローンとか、クラサバ(クライアント・サーバー=CLIENT-SERVER)という形式が主流でした。これらの形式のプログラムでは、入力された値をチェックするのは簡単なことでした。商品コードが正しいかどうかは、商品コードが入力された度に、値をデータベースに問い合わせて、正しければ商品名の欄に商品名を間違っていれば、赤字で警告を表示します。ユーザーが正しい値を入力した時点で、保存ボタンを有効にします。ところがWebプログラミングでは、簡単にことが進みません。入力された商品コードが、整数4桁でといったことは判断が付きます。入力された商品コードが正しいかどうかとは、データベースに問い合わせないとならないので、ブラウザ側(クライアントサイド)では判断が付きません。これを何とか解決したのがAJAXという技法です。入力の途中で判断して、サーバーに問い合わせ、その結果をリアルタイム(というは非同期)で、商品名や警告を表示します。クラサバのプログラムやスタンドアローンなプログラムでは、この入力された結果をそのまま、データベースに放り込んでも問題ありません。Webアプリケーションでは、そうは問屋がおろしません。Webアプリケーションというは、httpという開かれたプロトコルで書かれています。このため、途中から別のプログラムを使って、偽のデータを入れることができます。このためブラウザ(クライアントサイド)で入力されたものが、今度はWebサーバーでさらに正しいのか、確認する必要があります。入力時ではなくて、POSTの時点で検査するというこがvalidateという新しい?用語を割り当てることになった理由でしょう。今回は、PHPとjavascriptで透過で使えるようにしたvalidateクラスを紹介しようかと思っていたのですが、cpanで使えそうなライブラリがあったので、そちらを紹介して終わりにします。この記事の中で今流行のソーシャルメディアボタンでも設置してみようかなぁ・・と思います。ソーシャルメディアボタンとは何か?という方の為に説明から・・・。オンライン上で、ユーザー同士が情報を交換(送受信)することによって成り立っているメディア。「1対多」「多対多」の双方向で、画像・動画を含む視覚ツールを使ったコミュニケーションが可能なことも特徴とする。一般には、ブログをはじめ、2ちゃんねる、YouTubeなど閲覧者を制限しないオープンなサービスと、mixi(ミクシィ)、GREE(グリー)、モバゲーに代表される会員制・招待制のソーシャル・ネットワーク・サービス(SNS)に分けられる。最近は、上限140字の「つぶやき」をチャット感覚で投稿し、フォロワーとのゆるやかなコミュニケーションをはかるTwitter(ツイッター)が人気を集めている。いうことはソーシャルメディアボタンとは、ボタンがある記事やニュースの事を自分の利用しているSNSに対してすぐにつぶやいたり、ブログに書いたりできるようにする為のボタンだと私は思っています・・。最近はどこでもよく見るようになりましたので、アメブロや楽天ブログなどの大手ブログサイトでも標準でついていたりします。設置自体はすごく簡単で、SNSのサイトにはボタンを作ってくれる専用ページが存在しており、そこで発行されたタグをページに埋め込むだけ。それでは実際に設置をしてみます。以下のサイトに遷移すると日本語でわかりやすく書いてあるので特に作成には困らないと思います。※言語選択のタブから日本語を選択すると日本語になりますが、デフォルトは英語です。facebookは日本語での作成ができませんが、twitterと同様でそのままの設定を変更する必要なく設定できます。こちらもデフォルト英語表記ですので、発行されたタグの中のコードに含まれる「en_US」の部分を「ja_JP」に変更する必要があります。mixiのデベロッパー登録をしないとチェックボタンを付ける事ができません・・。設置しようと思ったのですが、なんせ時間が無く・・・・面倒なので・・・・今回はスルーします。下の方に行くと、iframe出力サイトというのがありますのでそこから作成します。GREEは他のSNSと違い、ボタンを設置するURLを自分で入力する必要があります。その為、ブログの記事につけたりする際は、タグのURLを動的に変更させる必要がありますね。いえ、GREEも簡単に設置できました。他のサイトに張り付けても動作するので、一度作成してしまえば流用がきいていいですね。次回は、mixiを設置するか違うボタンをいくつか付けてみたいなぁと思います。Yoshiテンプレートエンジンの話(2)2011-06-23Byyna,開発さて前回はテンプレートエンジンの前史のようなレベルの話だったのですが、もう少しましなレベルにしましょう。テンプレートエンジンを使用するということは、二つの側面があります。ひとつはプログラマが楽をすること(=生産性をあげること)、もうひとつは、サーバーの負荷を下げることです。RubyのテンプレートエンジンのeRBや、PHPのテンプレートエンジンのSmartyのような本格的なテンプレートエンジンは、テンプレートをRubyやPHPのソースコードにコンパイルします。最近のWebサーバーでは、一度使用したプログラムを中間コードの状態で保持しておいて、実行する機能がありますので、よく使われるサービスであれば、サーバーの負荷を下げることができます。個人的なツールであれば、生産性を上げるメリットのほうが大きくなります。PHPのSmartyは良くできたテンプレートエンジンなのですが、開発者の生産性を上げるという側面から見ると、いくつか不満もあります。MVC構造(モデル・ビュー・コントロール)の分離ということを考えるなら、入力部品の記述は本来テンプレート側に記述するべきなのだが、うまく記述できない。結果として、コントロール側のコードに書かざるを得ない。デザインとプログラムを分離できなくなっている。一応insert構文というものがあり、指定した名称のPHP側のコードを呼び出してはくれるが、あまり使い勝手は良くない。出来ればクラス化するなどで拡張性のできる仕組みにしたい。そこで、勉強をかねて自分で作ってみます。個人で片手間に作るのですから、コード量を減らす必要があります。Rubyは、レンタルサーバーで使えるところが増えてきていますが、まだまだです。その点、Perlはどこでも使えるというメリットがあります。CPANに山のように、いいテンプレートエンジンがありますが、そこは勉強と割り切りましょう。作成に関して、いくつかの指針を決めましょう。完璧を求めると、正規表現でちょこちょこと簡易パーサーを書くというようなことにはいかなります。自分が相対的に楽をするためのものと割り切ります。テンプレートエンジンの内部にHTMLコードが存在するのは、仕方が無いことです。本来HTML側に記述するようなstyleとかclassなどのHTMLのパラメータを、極力プログラム側で書かない。少なくともコントロールする必要がなければ、コード側で書かない。必要に応じて簡単に拡張できる仕組みをもつ。テンプレートエンジン自身は全体の9割までの必要を満たせばいいと割り切り、コードサイズを小さくします。コードサイズが小さければ、クラスを拡張するときなど、ちょっとソースコードを参照して、追加したり手直ししたりが出来ます。ベースとなる考え方ですが、HTMLライクなテンプレートを読み込んで、必要な埋め込みを行ってそのまま、出力するという仕組みにします。テンプレート側に、制御構造を持つとプログラムが大変になるので、埋め込みデータで制御をするようにします。前回の例で示したテンプレートのサブルーチンでは、制御を完全にプログラムで行うようにしていました。これではHTMLの形を変えると、プログラムで制御しないとなりません。ループ構造が複数回出てくる形式で、出現順番が変われば、プログラム側も修正しないとなりません。デザインとプログラムの分離ということでは、不完全すぎる仕様です。HTML自身は入れ子構造になっている仕組みなので、ブロックの単位も入れ子構造をとれば、都合がいいはずです。前のテンプレートのサブルーチンでは、セクションは、単に連続して並んでいましたが、ここでは入れ子構造にします。外側のセクションですが、無名というもの使いづらいので、MAINというセクション名を割り当てています。テンプレートエンジンは、読込を行った時点で新しいセクションがあれば、その位置にセクション用の埋め込みタグを埋め込みます。レンダリングするさいは、その記号を目印に置き換えます。xxx>などのコントロール部品です。これらは、プログラム側で制御が必要な上に、テンプレート側にもclassやstyleなどのパラメータが必要な厄介な代物です。名称で示された値をキーに、テンプレート側のパラメータとプログラムから渡されたハッシュ値を元に、コントロールを生成します。このコントロールの生成部分は、クラスメソッドになっており、変更や追加が簡単にできます。以下のような部品を用意しました。ファイルアップロードやイメージボタンなどは、まだ作成していません。この部分は以前のテンプレートサブルーチンをそのまま踏襲しています。使い勝手を考えると、Smartyのような修飾子が欲しいところです。ここについては、今後の課題にしたいです。テンプレートを見てみましょう。"value"=>"これが現実というものだよ。コードのほうもデータの構造はちょっと複雑ですが、プログラム的にはいたってシンプルな構造になっています。#LOOPというキーに紐付いたハッシュの参照があります。この参照先が偽であれば、LOOPで宣言されたセクションは展開しません。スカラー値で真であれば、空のハッシュで展開します。ハッシュへのリファレンスであれば、ハッシュ値を渡して展開します。配列への参照であれば、その配列の個数分だけ繰り返し展開を行います。テンプレートエンジンは、こちらを参照してください。renderをデータのパラメータを渡して展開します。renderLoopとrenderHashで実際のレンダリングをしています。callFuncは、埋め込み部品を生成する部分の大本の関数です。ここで、各埋め込み部品の生成関数を呼び出しています。html_xxxxxシリーズの関数は、埋め込み部品の関数です。現在のところ300行程度です。結果はこんな感じになります。今から15年位前、インターネットが始まったころ、動的なサイトを作るには、Perlという言語でCGIを作るのが一般的でした。そのころのプログラムは、Perlのプログラムの中にヒアドキュメントを用いてHTMLを強制的に埋め込むのが普通でした。上のような表一つ出すのにも、こんなコードを書いていました。HTMLとコードが混在してますし、HTMLとコードの順番もバラバラで、ちょっと何をやっているコードか分かりませんね。いう方法では、ちゃんと書くのは大変ということで、次第によく使われるようになったのが、ASPやPHPなどのHTML埋め込み型の言語です。さっきのPerlで書かれたプログラムよりは分かりやすいですよね。単純なHTMLしか作成しなかった頃にはこんな方法でも十分だったのですが、デザイン重視のHTMLが当たり前になり、デザイナーが作るようになると、HTMLとプログラムが分離しないということが問題になるようになってきました。ここで出てきたのはテンプレートとプログラムを分離して扱うという考え方です。このプログラムは、最も初期のテンプレートのサブルーチンです。コメントを入れても70行程度と、最近使われているSmartyのようなテンプレートエンジンに比べると赤ん坊のようなものです。load_templateでセクション記号ごとに分割してテンプレートをロードし、replace_htmlで特定の記号で囲まれたキーワード(ここでは、##~##)を置き換えます。この程度のサブルーチンでも、だいぶ見通しのよいプログラムを書けるようになりました。テンプレートファイルは、こんな感じになります。この程度の埋め込みであれば、デザイナーに渡しても戸惑うことなく作業してくれそうです。プログラム側ではこんな感じに使います。最初にHEADセクションを表示して、それから、LOOPをデータ個数だけ繰り返して、最後にTAILを表示するようになっています。次回は、もう少し進んだ形のテンプレートエンジンの話をしましょう。Usご不明な点や、気になったことなど、お気軽にお問い合わせください。エンジニア採用、デザイナー採用を行っています。