PEAK XOOPS - News

外部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として利用されます。
ここでのオプションはキャッシュ時間となります。キャッシュが効いている間は、この「ローカル保存」より前のジョイントは通過しません。


以上の説明は、難しかったでしょうか？
まずは、気に入ったフィードを登録して、保存してみてください。
そこにコメントをつけたりしているうちに、なんとなく使い方が判ってくるはずです。

D3 Pipesは、どのようにジョイントを組み合わせるかが全てです。

その組み合わせだけなら無限にあって、何がなんだか判らなくなってしまうでしょうが、実際には、パイプのパターンはほぼ３つしかありません。

(A) 外部XML取得パイプ
XML取得 -> UTF8への変換 -> XML解析 -> 内部エンコーディングへの変換 -> 抽出 -> 保存

(B) 内部情報取得パイプ
ローカル取得またはブロック取得 -> 抽出

(C) 集約パイプ
集約 -> ソート

（OPMLパイプというものも将来的に予定していますが、これは(A)と(C)の組み合わせと考えることも出来ます）

まずは、(A)パターンを構成してみます。

パイプ管理から「新規パイプ作成」に入ると、最初から「外部から取得:snoopy」「XML解析:keithxml」「コード変換(UTF8から):mbstring」「ローカル保存:moduledb」が開いているはずです。

実は、オプションの一番上に、RSSやATOMのURIを入力すれば、それだけでパイプとして構成完了です。（名称くらいはつけた方が良いでしょうが）

d3pipesの公開側に入ってみれば、何らかの表示がされているはずです。エラー表示がされている場合は、そのメッセージに従ってください。

次回は、この(A)パターンをもう少し詳しく見ます。

D3 Pipesとは、内外のシンジケーション情報を自在に扱うためのモジュールです。
名前からも機能からも、某!Pipesを予想させるでしょう。

ただ実は私、某!Pipesを使ったことは一度もありません。（アカウントすらない）
あくまでITMediaの紹介記事を読んだだけであり、概念くらいしか知りません。
その紹介記事からインスパイアされて作っただけなので、もしかしたら、まったく違うものである可能性はあります。


さて、xhldを開発していて、何より苦労したのは、環境依存があまりにも多いことです。xhldでは、個別に対応して、その都度パッチを当てていたのですが、結果的にレンダラクラスばかりが肥大する、という結果になりました。

問題となった環境依存とは以下のようなものです。

-取得処理
--allow_url_fopen設定 (onならfopenが使えるがoffならsocketを使うしかない)
--curlの有無/パス (snoopy利用時のhttpsアクセス)
--Proxyをどう超えるか

-解析処理
--XMLの文字エンコーディング (mbstring/iconv)
--RSS1/RSS2/ATOMのフォーマットの違い
--どの要素にどのデータが載っているか(サイトによって千差万別)
--規則に違反しているXMLの処理

-絞り込み処理
--国際化を考えるとpreg_matchしか使えないが、マルチバイト圏ではmbregexでないと使い物にならない

-保存処理
--内部エンコーディング (mbstring/iconv)

-集約処理
--発行日のないエントリをどう扱うか

-表示処理
--どの要素を表示するか
--どの要素をエスケープするか/しないか


…とまあ、実際キリがなく、嫌になるほどです。

ところが、RSSの処理をパイプに見立てて、上述した各動作を、ジョイントとして機能的に分解してみると、驚くほどすっきりとしたコードになったのです。外部XMLを取得・表示する1本のパイプは以下のようなジョイント構成になります。

Joint -> Joint -> Joint  ->  Joint
元のXML  utf8XML  utf8配列  内部配列

某!Pipesっぽいモジュールを作ってみました。
とはいえ、あんなインターフェースを個人の余暇で作りきれるはずもないので、あくまで機能として近い、というだけです。

正直言って、使い方がかなり難しいモジュールになってしまったのですが、上手に使いこなせば相当な可能性を秘めていると思います。

時間がないので、今日はリリース告知だけとします。
明日から、使い方について連載してみます。
（そしてできあがったものを添付ドキュメントにする、と）

なお、このモジュールはフルスクラッチであり、xhldとはまったく関連ありませんが、機能的には十分にxhldを含んでいると思われるので、今日をもってxhldは開発終了とします。

モジュールは基本的にDBテンプレートなのに、テーマだけがファイルテンプレートなのはおかしいよなあ、という程度の理由で、DBテンプレートでテーマを表示するモジュールを作ってみました。

http://xoops.peak.ne.jp/md/mydownloads/singlefile.php?lid=99&cid=1

一応、メリットを挙げておきます。

(1) altsysで編集できる（当然、差分表示も利用できる）
(2) CSSが自動的にテンプレート化される
(3) ブロック単位で任意のテーマを割り当てることができる（もちろんブロックは複製可）
(4) 「themes/からの自動更新」をOFFのままでもテーマ変更が反映される

メリットのそれぞれに裏があります。

(1) ローカルのエディタの方が速いかも
(2) CSS表示が重くなるかも
(3) 普通にtheme.html内で振り分けた方が判りやすいかも

ただ、(4)だけは純粋にメリットかもしれません。みんな気軽に使っている一般設定の「themes/からの自動更新」ってオプション、実はとっても恐ろしいですから