Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

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

by Melly (Hermit)
on Apr 27, 2011 at 16:14 UTC ( #901608=note: print w/replies, xml ) Need Help??

in reply to Re: Using XML::XSLT to convert XML to CSV
in thread Using XML::XSLT to convert XML to CSV

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,$e**2 -$d**2+$b);$c=$d**2+$e**2>4?$d=8:_}1..50;print$c}0..59;print$/}0..20
Tom Melly, pm (at) cursingmaggot (stop) co (stop) uk

Replies are listed 'Best First'.
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.

    Enoch was right!
    Enjoy the last years of Rome.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://901608]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (3)
As of 2018-05-21 23:41 GMT
Find Nodes?
    Voting Booth?