PEAK XOOPS - News 
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配列 内部配列
-取得(fetch)
--fopen/snoopyから選択
--オプションは取得すべきURI
--先方に迷惑をかけないように最低限の取得キャッシュは利用する
-UTF-8への変換(utf8from)
--mbstring/iconv/iso88591から選択
--オプションはそのXMLのエンコーディング
--UTF-8以外のXMLは、先にUTF-8にしておく
-XML解析(parse)
--現在はkeithxmlのみ。
--オプションは RDF/RSS/ATOM のいずれかとしているが、可能な限り自動判別すべき
--将来的に PEAR:XML* エンジンベースのを追加してもよい
-UTF-8からの変換(utf8to)
--mbstring/iconv/iso88591から選択
--オプションは内部エンコーディング
-絞り込み(filter)
--mbregex/pcreから選択
--オプションは絞り込みパターン
-ローカル保存(clip)
--現在はmoduledbのみ
--オプションはローカル保存をキャッシュとして利用する時間(sec)
--ローカル保存することで検索/コメント/マーキングが可能となる
-集約(union)
--現在はmergesortのみ (集約してpubtimeでソートする)
--オプションはパイプ番号（と、各パイプからの最大件数）をカンマで区切ったもの
#…と、ここまで書いて、「集約」と「ソート」は別のジョイントして分けた方がいいような気がしてきました。（近く対応する予定）
初回からヘビーな話になってしまいましたが、この開発背景を知っていると、D3 Pipesの使い方も良く理解できると思って、あえて原理を説明しました。
次回からはもう少し易しくなる予定です。
某!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/からの自動更新」ってオプション、実はとっても恐ろしいですから
davidl2さんからPMをもらって知ったのですが、こんなレポートが出ているそうです。
http://www.securityfocus.com/bid/23229
えっと…、myAlbum-P 2.0
2.0? 目を疑いました。
いやまあ、そりゃあSQL Injectionくらいあるでしょうね。
2.0をリリースした3.5年前なんて、右も左も判らないでPHPスクリプトを書いていた頃ですから。
現在メンテナンスされていないモジュールならともかく、少なくとも3年は前に塞いである穴を今になってレポートするって意味がわかりません。
ただ、「いくらなんでも、こんな古いモジュールをそのまま使っている人はいないよなあ」、とググってみたら、いるわいるわ。
うちにも、このレポートを利用した攻撃(?)が来てました。
未だにmyAlbum-P 2.0をそのまま利用している人にはどんなアナウンスも無駄だとは思いますが、一応ここで警告しておきます。
今すぐ、myAlbum-Pを最新版に上げるか、Protectorをインストールしてください