To be honest, if Marco has been annoyed at doc_base, I can't really
blame him. A few things we were doing in doc_base were non-kosher for
dhelp. These will all be fixed in the next version:
1) modifying .dhelp files without running dhelp_parse -d <dir> first
2) not using dhelp's (rather odd, IMHO) lower-cased document hierarchy
(Marco, let me know if you intend to change this to up-casing the
first letter, I'll need to track whatever you do.)
3) not doing a very good job at parsing existing dhelp files
4) not doing a very good job at creating dhelp files (i.e., only
allowing one <item> in a .dhelp, even if there should be more
Marco, please continue to let me know if I'm doing anything wrong in
dhelp. Hopefully I should have an update for all these problems
tomorrow.
With respect to parsing, BTW, here's my dhelp file parser in a Perl
nutshell. $_ (the implicit matcher for 'm{}') contains an entire
.dhelp file. I have confirmed this on all .dhelp files I could lay my
hands on:
while ( m{
<item>\s* # item defines a block, required
(?: # alternate everything group
(?:<directory> # directory is starting, required
([^<]+) # $1
) # ... ending
|
(?:<dirtitle> # dirtitle is starting, optional
([^<]+) # $2 until next tag start
) # ... ending
|
(?:<linkname> # linkname is starting, optional
([^<]+) # $3
) # ... ending
|
(?:<filename> # filename is starting, optional
([^<]+) # $4
) # ... ending
|
(?:<description> # filename is starting, optional
(.*?) # $5, non greedy
</description>) # ... ending
)* # end alternating
\s*</item> # spaces ok, item ends
}gscx )
{
@rets = ($1, $2, $3, $4, $5);
@rets = map { chomp; $_; } @rets;
# push a hashref of our dhelp data item onto the $dhdata array
push(@$dhdata, {
'directory' => @rets[0],
'dirtitle' => @rets[1],
'linkname' => @rets[2],
'filename' => @rets[3],
'description' => @rets[4],
});
}
Perl is cool!
.....A. P. [EMAIL PROTECTED]<URL:http://www.onShore.com/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
