Re: Using XML::XSLT to convert XML to CSV

Why is your skeletal beginning longer than a complete solution?

use strict;
use XML::Rules;
use Text::CSV_XS;
use FileHandle;

my $csv = Text::CSV_XS->new({eol => "\n"});
my $parser = XML::Rules->new(
    rules => [
        _default => 'content',
        HOUR_DATA => sub {
            $csv->print( $_[4]->{parameters}, [
                map {$_[1]->{$_}} qw(
                    LOCATION_NAME EFFECTIVE_DATE HOUR
                    CLC DPT HUM DBT WDR WSP HIX WCH
                )
            ]);
            return;
        }
    ]
);

open my $FH, '>&STDOUT';
print $FH "# relation, date, time, CloudCoverPct, DewPointF, Humidity,
+ TempF, WindDirection, WindMPH, HeatIndexF, WindChillF\n";

$parser->parse( \*DATA, $FH);

__DATA__
<?xml version="1.0" encoding="UTF-8"?>
<WEATHER_DATA>
<HOUR_DATA>
<LOCATION_NAME>KCNU</LOCATION_NAME>
<CLC>20</CLC>
<DPT>73</DPT>
<HUM>82</HUM>
<HIX>84</HIX>
<DBT>79</DBT>
<WCH>79</WCH>
<WDR>210</WDR>
<WSP>17</WSP>
<EFFECTIVE_DATE>08/20/2007</EFFECTIVE_DATE>
<HOUR>14:00</HOUR>
<TIME_GENERATED>08/20/2007 09:45:00</TIME_GENERATED>
</HOUR_DATA>
<HOUR_DATA>
<LOCATION_NAME>KCOU</LOCATION_NAME>
<CLC>100</CLC>
<DPT>71</DPT>
<HUM>87</HUM>
<HIX>79</HIX>
<DBT>75</DBT>
<WCH>75</WCH>
<WDR>190</WDR>
<WSP>13</WSP>
<EFFECTIVE_DATE>08/20/2007</EFFECTIVE_DATE>
<HOUR>14:00</HOUR>
<TIME_GENERATED>08/20/2007 09:45:00</TIME_GENERATED>
</HOUR_DATA>
</WEATHER_DATA>
[download]

Jenda
Support Denmark!
Defend the free world!

Comment on Re: Using XML::XSLT to convert XML to CSV Download Code

Replies are listed 'Best First'.
Re^2: Using XML::XSLT to convert XML to CSV by Melly (Chaplain) on Apr 27, 2011 at 16:14 UTC
Hi - can anyone explain what the previous bit of code is doing - specifically, how is `$_[4]->{parameters}` an output filehandle? edit to add - ach, my bad. Just noticed that this is coming from XML::Rules rather than CSV_XS... still, any insights always welcome... `map{$a=1-$_/10;map{$d=$a;$e=$b=$_/20-2;map{($d,$e)=(2$d$e+$a,$e2 -$d2+$b);$c=$d2+$e2>4?$d=8:_}1..50;print$c}0..59;print$/}0..20` [download] Tom Melly, pm (at) cursingmaggot (stop) co (stop) uk	[reply] [d/l] [select]
Re^3: Using XML::XSLT to convert XML to CSV by Jenda (Abbot) on Apr 27, 2011 at 23:08 UTC
XML::Rules lets you specify "rules" to be evaluated whenever a tag (including the content and subtags if any) is parsed and processed. The rule may be either one of the builtins ("keep only the content", "use this attribute as the key and that attribute as the value", ...") or a subroutine to be called. If you specify a subroutine, then that subroutine is called with five parameters, the tag name, the hash of attributes (containing also the content and whatever values were produced by the rules for subtags), the array of currently opened tags enclosing the one being processed, the array of attribute hashes for those tags and the parser object. You may either assign the parameters to local variables or access the parameter array @_ directly. So `$_[4]` is the parser object. The parser object is a blessed hash and there are several keys that may be used by the subroutine rules. One of them is {pad} (`$_[4]->{pad}` inside the subroutine) ... it's reserved for the rules and you can put anything you want there in case you need to keep some state information between the subroutine calls. Another is {parameters}. This is again reserved for data specific to your rules, but may be assigned by the ->parse(), ->parsefile(), ->filter() and other such methods. So if you need to pass some data to your rules and do not want to use global variables you pass that data to the ->parse() method as the second parameter and then find it in `$_[4]->{parameters}`. In that script, the second parameter to `$parser->parse()` was the filehandle so that's what you then find in `$_[4]->{parameters}`. I might have declared the $FH on top of the script and then access it directly from the subroutine, but I do not like to do that. I believe the rules should be as "selfcontained" as possible so that (in this case) if you wanted to use the parser twice and print the results to two different files, you could just pass the filehandle to print to to the ->parse() instead of depending on some global variable. Do I make sense? I tried to explain the XML::Rules in its docs and in several nodes here, but it's still a bit hard to understand if you are not used to callbacks or functional programming. Jenda Enoch was right! Enjoy the last years of Rome.	[reply] [d/l] [select]