D3 Pipes is a module for treating syndications of inside/outside.
There are too many "Environmental dependencies" in treating outside XML.
-fetch
--allow_url_fopen on/off
--curl exits/not
--How to pass firewall
-parse
--encoding of the XML (mbstring/iconv)
--RSS1/RSS2/ATOM
--correspondence between tag and data
--invalid XML
-filter
--preg is hard to use for multibyte environment
-store
--internal encoding (mbstring/iconv)
-aggregation
--how to sort entries without publised time
-display
--Which element should be displayed
--Which element should be escaped
In xhld, a class of headlinerenderer handles all dependencies.
Thus, it had been "too big" and "hard to use" codes.
The pipe model solves the problems smartly.
A sample of the pipe model:
Joint -> Joint -> Joint -> Joint
XML utf8string utf8array array
These are joints composing a pipe.
-fetching XML string (fetch)
--select fopen/snoopy
--set URI as its option
-converting XML string to UTF-8 (utf8to)
--select mbstring/iconv/iso88591
--set XML's encoding as its option
-XML parsing into array (parse)
--keithxml only (should be added one based PEAR:XML* engine)
--set RDF/RSS/ATOM as its option
-converting entries from UTF-8 to internal encoding(utf8to)
--select mbstring/iconv/iso88591
--set internal encoding as its option
-extracting entries (filter)
--select mbregex/pcre
--set regex pattern as its option
-clipping into local (clip)
--moduledb only
--set local cache time as its option (sec)
-aggregation(union)
--mergesort only
--Set (pipe_id):(num),(pipe_id):(num) as its option eg) 1:10,2:5
# The joint of union will be devided into "union" and "sort"
I believe that understanding the principle makes you easy to use D3 Pipes.