Main Page | Class Hierarchy | Alphabetical List | Class List | File List | Class Members | File Members | Related Pages

ConduitSource Class Reference

Inheritance diagram for ConduitSource:

IConduitSource List of all members.

Public Member Functions

int reader (void[] dst)

Protected Member Functions

void bind (IConduitSource next)
void unbind ()

Protected Attributes

IConduitSource next

Detailed Description

Defines an input filter base-class. The filter is invoked via its reader(void[]) method whenever a block of content is being read; the void[] array represents content destination. The filter should return the number of bytes it has actually produced: less than or equal to the length of the provided array.

Filters are chained together such that the last filter added is the first one invoked. It is the responsibility of each filter to invoke the next link in the chain; for example:

class MungingInputFilter : FilterInput { int reader (void[] dst) { // read the next X bytes int count = next.reader (dst); // set everything to '*' ! dst[0..count] = '*'; // say how many we read return count; } }

Notice how this filter invokes the 'next' instance before munging the content ... the far end of the chain is where the original IConduit reader is attached, so it will get invoked eventually assuming each filter invokes 'next'. If the next reader fails it will return IConduit.Eof, as should your filter (or throw an IOException). From a client perspective, filters are attached like this:

FileConduit fc = new FileConduit (...); fc.attach (new ZipInputFilter); fc.attach (new MungingInputFilter);

Again, the last filter attached is the first one invoked when a block of content is actually read. Each filter has two additional methods that it may use to control behavior:

class FilterInput : IFilterInput { protected IFilterInput next; void bind (IFilterInput next) { this.next = next; } void unbind () { } }

The first method is invoked when the filter is attached to a conduit, while the second is invoked just before the conduit is closed. Both of these may be overridden by the filter for whatever purpose desired.

Note that an input filter can choose to sidestep reading from the conduit (per the usual case), and produce its input from somewhere else entirely. This mechanism supports the notion of 'piping' between multiple conduits, or between a conduit and something else entirely; it's a bridging mechanism.

Definition at line 366 of file Conduit.d.


Member Function Documentation

int reader void[]  dst  ) 
 

conduit-specific reader

Reimplemented from IConduitSource.

Referenced by testConduitFilters().

void bind IConduitSource  next  )  [inline, protected]
 

Reimplemented from IConduitSource.

Definition at line 380 of file Conduit.d.

void unbind  )  [inline, protected]
 

Reimplemented from IConduitSource.

Definition at line 390 of file Conduit.d.

References IConduitSource::unbind().


Member Data Documentation

IConduitSource next [protected]
 

Definition at line 368 of file Conduit.d.


The documentation for this class was generated from the following file:
Generated on Sun Nov 7 19:07:01 2004 for Mango by doxygen 1.3.6