PEAK XOOPS - News 
XOOPSでは伝統的に、日本語はjapanese、英語はenglishとしてきましたが、エンコーディング情報が入っていないために、混乱を招いてきました。
XoopsCubeでは、minahitoさんの提唱で、
(言語名)_(エンコーディング) ※言語名は2文字。全部小文字。
を原則的なルールとすることに決まったようです。
例えば、UTF8エンコーディングされた日本語ファイルは、ja_utf8 です。
同じく、EUCの日本語ファイルは、ja_euc となるはずですが、こちらについては、過去の資産との関係で、しばらくは japanese のままで進行するでしょう。
拙作モジュールでは、UTF8エンコーディングされた日本語ファイルを japaneseutf という名前で置いてきましたが、今後は ja_utf8 という名前に統一します。
今後のリリース作業で、徐々に切り替えていきますので、そのあたりの進行の遅さはご容赦ください。（今すぐ必要なら、ディレクトリ名をjapaneseutfからja_utf8に変えるだけです）
なお、XoopsCube Legacy 2.1.0 では、数字の入った言語名を選択できません。今回の命名法決定にあたり、2.1.1以降ではここに修正が入る予定です。もし今すぐ、ja_utf8に切り替えるのであれば、CVSの最新版を落としてください。
XOOPS (Cube2.1も) でinstallフォルダを残しておくと、管理画面で警告が出ます。
というのも、installフォルダを経由すれば、DBパスワードなどがダダもれになってしまうからです。
ただ現実に、アップグレード時にintallフォルダもアップロードしてしまうとか、installフォルダを簡単なリネーム(_installとか)だけして放置しておく、なんてことは当然考えられます。
その対策って、とても簡単であることにふと気づきました。
'_INSTALL_CHARSET' という定数が定義された状態で、mainfile.php を実行されることは、インストーラ以外にないのです。この定数は、X2,本家2.2, XCLegacy 2.1 いずれでも共通なので、そのまま使えます。
だから、Protectorのprecheckにおいて、この定義があった時点で強制終了するだけでOKです。この方法であれば、_install などの簡単なリネームがバレたケースにも対応できます。もし、なんらかの理由で、本当にインストーラを利用したければ、Protectorを一時的に外せば良いでしょう。
少なくともインストール後、Protectorさえちゃんとインストールすれば、後からinstallフォルダをアップロードしてしまう等のミスをやっても情報漏洩はある程度防げます。（インストール途中で放置しちゃったケースでは対応できませんが、まあ、まだサービス開始もしていないサイトならDBパスワードなどを一通り変更して、もう一度最初からやり直せば良いでしょう）
というわけで、Protector-3.03にそのチェックを入れました。定数定義のチェックが１行あるだけなので、速度的な影響はほとんどないはずです。
D3モジュールの言語定数は、XOOPS_ROOT_PATH側に言語定義ファイルを置くことで、各モジュール毎にオーバーライドできる、なんて話を書きましたが、実際に試してみたらかなり使いづらい、というのが実情です。例えば、モジュールがバージョンアップして、言語定義が増えた場合に、それを簡単に更新する術がありません。
また、仮にもCMSなのに、HTTP経由ではちょっとしたメッセージ変更すらできない、なんていうのもあまり格好良くありません。
というわけで、altsys-0.5に、言語定数オーバーライドシステムを実装してみました。その主要構成部は２つ。
- mylangadmin
myblocksadminやmytplsadminと同じく、各モジュールの管理画面から呼び出されるコントローラです。ここで上書きされた言語定数を、定数名ごとにDB(altsys_language_constants)に保存し、XOOPS_ROOT_PATH/cache/ 下にキャッシュとして書き出します。
- D3LanguageManager
モジュール/コアが言語定数を読み込むときに使うシングルトンクラスです。実際には、mylangadminによって作成されたキャッシュがあればそれを優先的に読み込むだけの処理だったりします。
以下のように呼び出します。
require_once XOOPS_TRUST_PATH.'/libs/altsys/class/D3LanguageManager.class.php' ;
$langman =& D3LanguageManager::getInstance() ;
$langman->read( 'main.php' , $mydirname , $mytrustdirname ) ;
とりあえずは、pico-1.31に実装してみました。言語定数を管理画面から簡単にオーバーライドできるのは、結構、快感かもしれません。
また、モジュールがバージョンアップして、言語定義が増えた場合でも、DBとキャッシュという２段構造をとっているため、言語定数管理からあらためてキャッシュ更新を行うだけで、簡単に更新できます。（もう少し自動化できたらなおベストか……onUpdate?）
現状では、言語定数を独自に読み込むD3モジュールにしか利用できませんが、言語定数読込部分を換装可能に作ってあるコア(例えばXoopsCube Legacy 2.1)であれば、mylangadminで従来型モジュールの言語定数をオーバーライドすることも難しくないでしょう。（altsys側にももう少し手を入れる必要があるでしょうが）
使い方の説明はちょっとお休みして、ジョイントの作り方を解説してみます。
他のサイトから更新データを引っ張ってきたい時、業種によってはRSSが提供されていないことも多くあるでしょう。そういうサイトでは、HTMLを解析するしかありません。
逆に言えば、d3pipesであれば、HTMLを解析するジョイントクラスだけを作ればいいのです。取得もアグリゲーションも絞り込みも保存も表示も、そのまま使えます。
※どんなサイトもRSS化する、なんてサービスもありますが、それだと細かい所に手が届きません。サイト個別に対応するなら、専用の解析ジョイントを書くのが一番です。
さっそく作ってみましょう。今回は解析ジョイントを作るので、クラス定義ファイルの置き場所は、ここになります。
XOOPS_TRUST_PATH/modules/d3pipes/joints/parse/
HTMLからヘディングをとってくるだけなので、Simplehtmlという名前にしましょう。
クラス名は、D3pipesParseSimplehtmlに、ファイル名は、D3pipesParseSimplehtml.class.php となります。
※ クラス名やファイル名は、Camel表記である点に注意が必要です。
クラスファイルの中身では、基本的にexecute()メソッドを記述するだけです。どういうデータを受け取って、どのように返すかは、ジョイントの種別によって違います。解析ジョイントの場合、テキストファイルからエントリ配列を返します。
HTMLを解析する方法にもいろいろありますが、ここでは最もシンプルに正規表現で抜き出します。いろんな抜き出しパターンがあると思われるので、パターン部分はオプションで指定できるようにしましょう。そうすれば、別のサイトにも使い回しが効くかも知れません。
最後に添付したリストを見れば、とっても簡単なことが判るはずです。各エントリに最低限必要な要素は４つです。
'heading' : 見出し
'pubtime' : 発行日時のUnixTimestamp（ここでは、簡易的に取得時間としてますが、HTML内に発行日時の情報があれば、それを解析しても良いでしょう）
'link' : その記事へのリンク（絶対URI）。ここでは定義しようがないので、あとから、Defaultlink という再割り当てジョイントを使います。もし、その記事のURI情報がHTML内にあれば、それをここで割り当てておくべきです。
'fingerprint' : 記事の唯一性を保証するための指紋です。記事が独立したURIを持っていればそれを割り当てますが、ここでは単に見出しのmd5をとってます。
新しく作ったこのジョイントを使ったパイプを構成してみましょう。
そのページの h2 に見出し一覧がある、としてます。
0 外部から取得 snoopy (対象サイトのURI)
10 コード変換(UTF8へ) mbstring (対象サイトのエンコーディング)
20 XML解析 simplehtml #\<h2\>([^<]*)\</h2\>#iU
30 コード変換(UTF8から) mbstring EUC-JP (内部エンコーディング)
40 再割り当て defaultlink (対象サイトのURI)
50 ローカル保存 moduledb 86400
外部XML取得パターンの流れをもう少し詳しく見てみましょう。
(A) 外部XML取得パイプ
XML取得 -> UTF8への変換 -> XML解析 -> 内部エンコーディングへの変換 -> 抽出 -> 保存
1) XML取得 (fetch)
オプションで指定されたURIからXML文字列を取ってくるジョイントです。
対象がXMLである必要はありません。HTML等であっても、それをパースできるparseユニットと組み合わせれば良いわけです。
ジョイントの動作としては、HTTPアクセスした結果を渡すだけなので、単純なfopenでも良いのですが、allow_url_fopen=off 環境用に snoopy をデフォルトとしています。
2) UTF-8への変換 (utf8to)
最近はUTF-8でないフィードもほとんどないので、ほとんどのケースでこのジョイントは必要ないと思われます。（そのため、新規パイプ作成でもデフォルトでセットされていない）
フィードがEUCやSJIS、ISO-8859-1等の場合、明示的に指定する必要があります。オプションに変換元のエンコーディングを指定します。
ここでの変換は、文字列->文字列ですが、ジョイントとしては配列にも対応しています。
3) XML解析 (parse)
一番の肝となるジョイントです。
単なる文字列が初めて、意味のあるpipeデータ（配列）になります。
「XML解析」と名づけていますが、文字列の種類はXMLに限りません。
オプションには、XMLタイプを指定します(RDF/RSS/ATOMのいずれか)。
ここを空白にした場合は、可能な限り自動で判別します。
XML取得とペアである必要があります
4) 内部エンコーディングへの変換 (utf8from)
XML解析は基本的にUTF-8で行われるため、pipeデータもUTF-8の配列となっています。
これを内部エンコーディングに変換するのがこのジョイントの仕事です。
オプションには内部エンコーディングを指定します。
特に指定がない場合、一般設定で指定された内部エンコーディングに変換します。
5) 抽出 (filter)
RSS等から欲しい情報（エントリ）だけを取り出すためのジョイントです。
オプションには検索条件を記入します。
この記述法は、クラスによって異なり、mbregexの場合はPOSIX正規表現、pcreの場合は、preg_match()用の正規表現を記述します
mbregexもpcreも、条件にヒットしたエントリだけを残すタイプのフィルターですが、条件にヒットしたエントリを削除するタイプのフィルターを作っても良いでしょう。
このジョイントは、いろいろな場所で挟む可能性があります。
複数の抽出ジョイントを連続して使うケースもあれば、あえて「保存」後にフィルターをかけるケースもありえるでしょう。
6) ローカル保存 (clip)
外部XML取得パターンの最後に入れたいのが、この保存ジョイントです。もちろん、一切保存しない、という選択肢も当然アリでしょうし、集約パイプの最後にだけ入れる、というパターンもあり得ます。
ただ、保存ジョイントを入れた場合と入れない場合では、動作がまったく違ってきます。
ローカル保存した場合、画面表示されたり、RSS出力されたりするのは、保存されたエントリデータとなります。
保存されたエントリデータ１つを、d3pipesでは「切り抜き」と呼びます。
切り抜きには、コメントをつけることが可能です。また、マークをつけることも可能です。
重要なのは、既に保存された（切り抜き化された）データかどうかの判断です。それには、fingerprint(エントリの指紋)と呼ばれるフィールドを利用します。fingerprintが異なるエントリだけが、新しい「切り抜き」として保存されます。
RSS2の場合は<guid>が、ATOMの場合は<id>が、それぞれfingerprintとして利用されます。
ここでのオプションはキャッシュ時間となります。キャッシュが効いている間は、この「ローカル保存」より前のジョイントは通過しません。
以上の説明は、難しかったでしょうか？
まずは、気に入ったフィードを登録して、保存してみてください。
そこにコメントをつけたりしているうちに、なんとなく使い方が判ってくるはずです。