xml::filter::tee(3pm) [debian man page]

XML::Filter::Tee(3pm)					User Contributed Perl Documentation				     XML::Filter::Tee(3pm)

NAME

       XML::Filter::Tee - Send SAX events to multiple processor, with switching

SYNOPSIS

	   my $t = XML::Filter::Tee->new(
	       { Handler => $h0 },
	       { Handler => $h1 },
	       { Handler => $h2 },
	       ...
	   );

	   ## Altering the handlers list:
	   $t->set_handlers( $h0, $h1, $h2, $h3 );

	   ## Controlling flow to a handler by number and by reference:
	   $t->disable_handler( 0 );
	   $t->enable_handler( 0 );

	   $t->disable_handler( $h0 );
	   $t->enable_handler( $h0 );

	   ## Use in a SAX machine (though see L<XML::SAX::Pipeline> and
	   ## L<XML::SAX::Tap> for a more convenient way to build a machine
	   ## like this):
	   my $m = Machine(
	       [ Intake => "XML::Filter::Tee" => qw( A B ) ],
	       [ A	=> ">>log.xml" ],
	       [ B	=> *OUTPUT ],
	   );

DESCRIPTION

       XML::Filter::Tee is a SAX filter that passes each event it receives on to a list of downstream handlers.

       It's like XML::Filter::SAXT in that the events are not buffered; each event is sent first to the tap, and then to the branch (this is
       different from XML::SAX::Dispatcher, which buffers the events).	Unlike XML::Filter::SAXT, it allows it's list of handlers to be
       reconfigured (via "set_handlers") and it allows control over which handlers are allowed to receive events.  These features are designed to
       make XML::Filter::Tee instances more useful with SAX machines, but they to add some overhead relative to XML::Filter::SAXT.

       The events are not copied, since they may be data structures that are difficult or impossibly to copy properly, like parts of a C-based DOM
       implementation.	This means that the handlers must not alter the events or later handlers will see the alterations.

METHODS

       new
	       my $t = XML::Filter::Tee->new(
		   { Handler => $h0 },
		   { Handler => $h1 },
		   { Handler => $h2 },
		   ...
	       );

       set_handlers
	       $t->set_handlers( $h0, $h1, $h2 );
	       $t->set_handlers( {
		       Handler => $h0,
		   },
		   {
		       Handler => $h1,
		   },
	       );

	   Replaces the current list of handlers with new ones.

	   Can also name handlers to make enabling/disabling them by name easier:

	       $m->set_handlers( {
		       Handler => $validator,
		       Name    => "Validator",
		   },
		   {
		       Handler => $outputer,
		   },
	       );

	       $m->disable_handler( "Validator" );

       disable_handler
	       $t->disable_handler( 0 );	    ## By location
	       $t->disable_handler( "Validator" );  ## By name
	       $t->disable_handler( $h0 );	    ## By reference

	   Stops sending events to the indicated handler.

       enable_handler
	       $t->enable_handler( 0 ); 	   ## By location
	       $t->enable_handler( "Validator" );  ## By name
	       $t->enable_handler( $h0 );	   ## By reference

	   Stops sending events to the indicated handler.

AUTHOR

	   Barrie Slaymaker <barries@slaysys.com>

COPYRIGHT

	   Copyright 2002, Barrie Slaymaker, All Rights Reserved

       You may use this module under the terms of the Artistic, GNU Public, or BSD licenses, as you choose.

perl v5.10.0							    2009-06-11						     XML::Filter::Tee(3pm)

Check Out this Related Man Page

XML::SAX::Tap(3pm)					User Contributed Perl Documentation					XML::SAX::Tap(3pm)

NAME

       XML::SAX::Tap - Tap a pipeline of SAX processors

SYNOPSIS

	   use XML::SAX::Machines qw( Pipeline Tap ) ;

	   my $m = Pipeline(
	       "UpstreamFilter",
	       Tap( "My::Reformatter", *STDERR ),
	       "DownstreamFilter",
	   );

	   my $m = Pipeline(
	       "UpstreamFilter",
	       Tap( "| xmllint --format -" ),
	       "DownstreamFilter",
	   );

DESCRIPTION

       XML::SAX::Tap is a SAX machine that passes each event it receives on to a brach handler and then on down to it's main handler.  This allows
       debugging output, logging output, validators, and other processors (and machines, of course) to be placed in a pipeline.  This differs from
       XML::Filter::Tee, XML::Filter::SAXT and XML::SAX::Distributer in that a tap is also a pipeline; it contains the processoring that handles
       the tap.

       It's like XML::Filter::Tee in that the events are not buffered; each event is sent first to the tap, and then to the branch (this is
       different from XML::SAX::Dispatcher, which buffers the events).

       It's like XML::SAX::Pipeline in that it contains a series of processors in a pipeline; these comprise the "tapping" processors:

		   +----------------------------------------------+
		   |		      Tap instance		  |
		   |						  |
		   |  Intake					  |
		   |  +-----+	 +---------+	    +---------+   |
	upstream --+->| Tee |--->| Stage_0 |--...-->| Stage_N |   |
		   |  +-----+	 +---------+	    +---------+   |
		   |	     					  |
		   |	       			 Exhaust  |
		   |	       +----------------------------------+--> downstream
		   |						  |
		   +----------------------------------------------+

       The events are not copied, since they may be data structures that are difficult or impossibly to copy properly, like parts of a C-based DOM
       implementation.

       Events go to the tap first so that you can validate events using a tap that throws exceptions and they will be acted on before the tap's
       handler sees them.

       This machine has no "Exhaust" port (see XML::SAX::Machine for details about "Intake" and "Exhaust" ports).

METHODS

       new
	       my $tap = XML::SAX::Tap->new( @tap_processors, \%options );

AUTHOR

	   Barrie Slaymaker <barries@slaysys.com>

COPYRIGHT

	   Copyright 2002, Barrie Slaymaker, All Rights Reserved

       You may use this module under the terms of the Artistic, GNU Public, or BSD licenses, as you choose.

perl v5.10.0							    2009-06-11							XML::SAX::Tap(3pm)

Linux and UNIX Man Pages

xml::filter::tee(3pm) [debian man page]

Check Out this Related Man Page