Smartyのタグって変更できるって知ってました？

http://smarty.php.net/manual/en/language.escaping.php

Smartyを使うとJavaScriptに{literal}{/literal}をつかうから不便だと。そういうブログを見たことがある。

なんで詳しく調べもしないでそういう事言うかなぁと、Smartyの制作者の不満が聞こえてきそう・・・

Example 3-7. changing delimiters example

<?php $smarty = new Smarty; $smarty->left_delimiter = '<!--{'; $smarty->right_delimiter = '}-->'; $smarty->assign('foo', 'bar'); $smarty->display('example.tpl'); ?>

Where example.tpl is:

<script language="javascript"> var foo = <!--{$foo}-->; function dosomething() { alert("foo is " + foo); } dosomething(); </script>

このポイントはSmarty:delim変数を使う点。

上の例ではSmartyの特殊文字を 「<!--{」 「}-->」のペアに変更してる。これでJavaScriptやCSSにも邪魔されないですよね？

個人的にはASPやJSPで使うタグ <%%> にすることをオススメしたい。JSPが大好きだから。というかHTMLしか知らないデザイナーさんには<%%>が一番わかりやすい。

$smarty->left_delimiter = '<%';
$smarty->right_delimiter = '%>';

こうしておけばSmartyタグは｛｝から<%%>に変更されます。

--------------追記

<% %> を使うと　PHP.ini allow_asp_tagの相性問題が出そうなのでそのうち調べておきます。

-------------追記２

Smartyのインスタンス毎にSmartyのASPタグを変えると楽しいことが出来ます。hatenaプラグインがやってるような独自Blogタグをに作ってしまえる。つまり、CMS提供元が提供するタグを "{" " }" のペアにしてユーザーがブログ入力に使うタグを "<tag:username" "/tag:username>" などと２つのタグをSmartyテンプレート内に共存させることが出来そう。

この応用は面白そうなので実際使ってみて、レポート書きます。

GoogleのAPIキーを使ってやること。

４年前のノートを見つけた。パソコンを初めて間もない頃だ。当時はネットさえ知らなかった。

「GoogleのAPIキーを使って、検索結果のサイトのページに何回検索語が出てくるか調べたい。」

とか書いてあった。

当時はまだ初心者で大学の授業でFORTRANをちょっと触ったくらいだった。今思うとよくもまぁこんな大それた事を思いついたものだ。ちょうどGoogleAPIの英語版が公開した直後だったかな。

つーかSEOを考えると、いまこのアイディアを実際にコードにしてみたいと思う。

「GoogleのAPIキーを使って、検索結果のサイトのページに何回検索語が出てくるか調べる。」
「GoogleAPIキーを使って、検索順位とページランクの関係を調べる。」
「Wgetを使って検索順位とページランクが高いサイトのページ枚数を調べる。」

この３つの相関関係何とか図式化出来ないものだろうか。

Googleの検索結果にキーワードが重要でページランクが重要で、ページ枚数の多い巨大サイトほどランクが高いという通説は事実なのか。

SEO業者に「王様はハダカ」である事実を何とかして突きつけたい。

SEO業者にSEOされたページははっきり言ってトラックバックスパムとあまり変わらない。つまり邪魔だ。

初期のインターネットとは遠くに離れた同好の人と情報交換する場であった。それがいまや、、、趣味のことを検索すると商品サイトに誘導され、広告をイヤと言うほど見せられ。。。。

プリキュアを検索すると性感ヘルスが上位に来る始末。>>

SEOとはユーザーに情報がわかりやすく、簡潔で安全なアクセシビリティーを提供するものだと思います。最近、HTTPSを理解していないネット企業があることに驚きました。

（自分で言い過ぎと反省です。）

Smartyを使ってユーザーがテンプレートの編集ができるCMSを作る

世の中には山のようにCMSがあふれているが。Smartyを使えば数時間でCMSを作れる。CMSを作るのは簡単だ。

POST　->　Smarty -> cache -> HTML -> ブラウザ

POST -> Smarty -> Smarty -> Template

の二つの流れが簡単に実装できる。

データーソースはXMLでいいじゃん。

SmartyをCMSに使う

CMS( blog, bbs )を作るとき、テンプレートにSmartyを使いたいとする。管理者がSmartyタグを書いてHTMLを変更したいが、不特定の誰かがBBSにSmartyタグ{php}{/php}など書き込みを想定してセキュリティー処理を施すのは面倒だ。あれこれを想定するとややこしい。

そこでSmarty::secureが使えるようだ。

http://smarty.php.net/manual/en/variable.security.settings.php

$security true/false, default is false. Security is good for situations when you have untrusted parties editing the templates (via ftp for example) and you want to reduce the risk of system security compromises through the template language. Turning on security enforces the following rules to the template language, unless specifially overridden with $security_settings :

なるほどね。なかなかに便利だ。CMSに使うと結構使えそうだ。hatenaでやってる独自タグなんかと同じ機能はSmartyタグで実現可能なわけですね。



secureで動作させれば不特定多数が操作するテンプレートにSmartyを使える。つまり、ユーザーがテンプレートを自作して鯖にアップするCMSもSmartyで作成できる。なかなかやりますなSmartyさん。

JSPからJSPを実行しJSPの内部からHTMLを参照する

数ヶ月間、google先生に質問してみたけどこれといった答えがなかったので自作した。（気の長い話だ）

JSP(servlet)の実行結果をServletから参照する。

PHPにはob_start()やob_end_flush()などが用意されているが。どうもJSPには用意されていないようで。。。

仕方ないので作りました。

JspOptputBuffer.java　JSPの出力をバッファリングしてCMSやキャッシュなどに再利用するクラス

package dev.util;
import javax.servlet.jsp.JspWriter;
import javax.servlet.jsp.tagext.BodyContent;
import javax.servlet.jsp.PageContext;
public final class JspOptputBuffer{
//pageContextの参照を持っておく
public javax.servlet.jsp.PageContext PAGE_CONTEXT;
//pageContextが作成するバッファ用OutputStreamを持っておく
public javax.servlet.jsp.tagext.BodyContent BODY_CONTENT;
//複数回バッファリングするときのためにStringを持っておく
public String BUFFERED_STRING;
//バッファリングを終了する
public javax.servlet.jsp.JspWriter close()throws Exception{
return this.PAGE_CONTEXT.popBody();
}
//バッファリングを開始する
public String getOutputBuffer()throws Exception{
return this.BODY_CONTENT.getString();
}
//バッファ内容を消去する
public void clearOutputBuffer()throws Exception{
this.BODY_CONTENT.clearBody();
}
//バッファリングを開始する
public javax.servlet.jsp.JspWriter start()throws Exception{
this.BODY_CONTENT = this.PAGE_CONTEXT.pushBody();
this.clearOutputBuffer();
return this.BODY_CONTENT;
}
//他のJSPを実行して結果をバッファリングする
public void include( String filename )throws Exception{
this.PAGE_CONTEXT.include( filename );
}
//コンストラクタ
public JspOptputBuffer(javax.servlet.jsp.PageContext pageContext )throws Exception{
this.PAGE_CONTEXT = pageContext;
}
}

test.jsp　　上記のクラスの利用例

<%@ page contentType="text/html; charset=Shift-JIS"
pageEncoding="Shift-JIS"
buffer="2048kb"
autoFlush="false"
import="dev.util.*,java.io.*;"%><%!
%><%
//Constructor
out.print(" aaa ");
JspOptputBuffer ob = new JspOptputBuffer( pageContext );
out = ob.start();
out.print(" bbb ");
out = ob.close();
out.print(" ccc ");
out.print(ob.getOutputBuffer()) ;
%>

実行結果は

aaa ccc bbb　　先のout.print(bbb)が後から出力される

この手法のミソはJSP暗黙オブジェクトのOUTをオーバーライドすることです。

このClassを応用すると事でJava＋JSPでもSmartyのような賢いキャッシュコントロールが可能になる。

他のJSPの実行結果をまとめてマージすることが出来る。HTML化が簡単になりキャッシュコントロールがやりやすくなる。

<%@ page contentType="text/html; charset=Shift-JIS"
pageEncoding="Shift-JIS"
buffer="2048kb"
autoFlush="false"
import="dev.util.*,java.io.*;"%><%!
%><%
//Constructor
out.print(" aaa ");
JspOptputBuffer ob = new JspOptputBuffer( pageContext );
out = ob.start();
out.include( "hoge.jsp?foo=bar" );
out = ob.close();
out.print(" ccc ");
out.print(ob.getOutputBuffer()) ;
%>

バッファリングしたJSPをHTMLに保存するなりGrepで再置換するなり、テンプレに埋め込むなり結構応用範囲は広い。JSP自体がSmarty並のテンプレートですから。Smarty並のキャッシュコントロールを実装すればかなり使える。まぁきっと世界のどこかで同じ事考えてる人はいるんだろうけど。

Smartyのcacheのコントロールで楽をするその２

Smartyのcacheのコントロールで、かなり楽が出来る。(以前の記事 )

ただ、PHPのデフォルト設定が

200 ok

no-cache

を返す設定になっている。

このままではキャッシュの効果が半減だ。Smartyが作成するサーバー側のキャッシュだけでなく、ブラウザのキャッシュも利用するとさらに効果的なのだ。

ブラウザのキャッシュを利用するにはE-tagを仕込むか、If-Last-Modified-Sinceに応答しなくちゃいけない

Smartyにはこの機能をサポートしている。

http://smarty.php.net/manual/en/variable.cache.modified.check.php

マニュアルによると

If set to true, Smarty will respect the If-Modified-Since header sent from the client. If the cached file timestamp has not changed since the last visit, then a "304 Not Modified" header will be sent instead of the content. This works only on cached content without {insert} tags.

この変数をTRUEに設定すると、SmartyはHTTP HEADERのIf-Modified-Since header を優先します。サーバー側にキャッシュされたファイルのタイムスタンプをつかい、ブラウザに304 NotModifiedを送信するかどうかSmartyが判断します。ファイルを送信する必要がないとき、Smartyは304を送信し、コンテンツは送信しません。ただし{insert}タグがテンプレートに利用されていない場合に限ります。

$smarty->cache_modified_check = true;

にしてやると良い。これで304を利用できる。If-Modified-Since が使えればE-tagまでサポートする必要ないだろう。

JPドメインはMIMEエンコードされたディレクトリ構造に強い？

仮説 JP ドメインはMIMEエンコードされたファイル名に強い？　追跡調査。

対象　検索ワード　「参考サイト」

検索結果。

http://www.google.com/search?q=%E5%8F%82%E8%80%83%E3%82%B5%E3%82%A4%E3%83%88&num=50&hl=ja&lr=&start=0&sa=N

はてなブックマーク　と　WebShot　の　比較。

http://b.hatena.ne.jp/t/%E5%8F%82%E8%80%83%E3%82%B5%E3%82%A4%E3%83%88

ページランク 0/10

検索順位　33　位

WebShots

http://s.phpspot.org/tag/all/%BB%B2%B9%CD%A5%B5%A5%A4%A5%C8%5Bl%A5%B5%A5%A4%A5%C8%5D

ページランク 0/10

検索順位　66　位

webshotsのページランクが大幅ダウンしてる。。。。

Ajaｘの用途って

Ajaxを使うことでUIをリッチにすることが出来るのですが。。。

Ajaxを使えば。アクセス解析が格段にやりやすい。Apacheのログに頼らないiFrameに頼らないアクセス解析が実現できる。

クリックを監視が格段に便利になる。何時何分何秒に誰がどのリンクをクリックした。

このページは何秒間閲覧された。

ユーザーがどのようにマウスを動かしたか。

等々。ユーザの動きを完璧にサーバー側に送信できてしまう。これってやばくないのかなぁ。（まぁiFrameを使っても実現可能だったのですが。。。）

Ajaxを使うことでブラウザの戻るボタンが使えない画面遷移が大量に出てくる可能性。これはアクセシビリティー的にどうなんだろう。

　セキュリティーとアクセシビリティーを考えるとAjaxの用途は非常に限定される。なにより1000行以上のXMLをXmlHttpで頻繁にやりとりするとJavaScriptでは処理がもたつく。いくらAnsyncといえども通信中＆XMLパースすれば処理がもたつく。実際問題としてiframeを使ったデータのやりとりで事足りるならiFrameの方が楽だ・・・ 1000件未満ならHTMLにDisplay :none;のデータを仕込んでしまった方が便利だし。

どのような場面でAjaxが効果的なのか？GoogleがやってるGmail、Suggestion、Map以外の利用法が思いつかない。あるとしたらhttp://script.aculo.us/ のドラッグ＆ドロップでショッピングカートくらいか。

xLoadTree(webfx)

WebFxのxloadTreeが便利なのでちょっと利用のテストしてみた

動的にツリーを作成するクラスはかなり便利。

PHPの　Windows ヘルプファイル chmをHTML＋Ajaxで作成しなおしてみましたhttp://docs.bookmacro.com/php/

マニュアル検索にもAjaxを実装してみたい。

BOMの話の続き

今のところはソースコードにはBOMを入れない方が無難らしいのだが。

XMLだとそうもいかない。

<?xml　version=1.0 encoding=utf-8 ?>

PHPのDOMDocument ClassはXMLのエンコーディング指定をUTF-8にするとBOMを要求する。

PHP自身はBOMの扱いがいい加減なのに、XMLをDOMするときに限ってBOMを要求する。何でだ。不UTF-8にBOMは不要なはずなのに。。。

結構めんどくさいです。

だからXMLはUTF-8＋BOMで記述。

UTF-8のBOMの操作できないエディタは捨てた方がいいのかも。

TeraPadとか秀丸とか・・・（対応済みだった）BOMの有り無しが選べるEmeditorは最高です。

JavaScritptをencodeURIComponentするとき

UTF-8だとBOMの扱いが変でBOM文字を大量にエンコードしてた気がする。直ったのだろうか。。。。

JavaScriptがエンコードする文字を意識しておきたい。

記号編

escape() 非推奨。ただし英語圏では結構好まれてる。

encodeURI

space " % < > [ / ] ^ ` { | }

encodeURIComponent

space " # $ % & + , \ : ; < = > ? @ [ \ ] ^ ` { | }

escape

space ! \ " # $ % & ' ( ) , : ; < = > ? @ [ \ ] ^ ` { | }

エンコードされる文字種も違うし順番も違う。

GET引数にURLやパスを含めるときはencodeURICompoentした方がいい。

ただし可読性が失われる。

IEでURLを常にUTF-8で送信するにチェックを入れておけばエンコーディングなしでも動くのだが。。。ださい

ちなみに俺がBOMBOMといってるのはUTF-8でエンコーディングしたら必ず先頭に入る３バイト。

%3B%2F%3F

のこと。エンコードに失敗すると

index.php?hoge=%3B%2F%3F%3B%2F%3F%3B%2F%3F%3B%2F%3F

とBOMだらけに。。。

この先頭の３文字文をBOMだと勝手に思いこんでるけど。間違いないよね。