org.expath.httpclient.model

Interface Result

public interface Result

An abstract representation of the result sequence. Accumulate result items from strings, bytes, JAXP sources and HTTP response objects. A specific implementation is obviously supposed to setup a way to provide the caller with the final result sequence within the processor's own object model. The items are added in order to the result sequence (in the same order than the method calls). Except for the HTTP response objects, which will be called once per result sequence, and always must be added to the front of the sequence.

Author:

Florent Georges

Method Summary

Modifier and Type	Method and Description
void	add(HttpResponse response) Add the http:response element to the result sequence.
void	add(java.io.InputStream bytes) Add raw binary to the result sequence.
void	add(java.io.Reader string, java.nio.charset.Charset encoding) Add a string value to the result sequence.
void	add(javax.xml.transform.Source src) Add a document node to the result sequence.
Result	makeNewResult() Construct a new Result object, from the same implementation.

Method Detail

makeNewResult

Result makeNewResult()
              throws HttpClientException

Construct a new Result object, from the same implementation. TODO: This mechanism is not satisfactory. It forces the user of the class HttpClient to down cast the result of sendRequest() to its own implementation of Result. A better approach would be to make this an abstract class, that forwards everything to some RequestResult interface. The abstract method would be a factory method as well, but then the client could add its own way to retrieve its own RequestResult, with the correct type. A RequestResult object would represent the result of one HTTP request on the wire, so there could be a few in case of a authentication handshake, or a redirect, etc. TODO: Actually, an even better approach would be to say that the function http:send-request must send exactly only ONE request on the wire. Authentication back-and-forth, redirects, and other alike would then be implemented in XSLT and XQuery themselves, by providing a library on top of the extension function (taking some configuration XML element, with options, function items, etc., saying what to do in case of such events. That is, keep the extension implementation as a minimum, and share all the rest in XQuery and XSLT. That would simplify the specification as well, and increase compatibility.

Returns:

The new result object.

Throws:

HttpClientException - If any error occurs.

add

void add(java.io.Reader string,
         java.nio.charset.Charset encoding)
  throws HttpClientException

Add a string value to the result sequence.

Parameters:

string - The string to add to the result sequence.

encoding - the charset encoding of the string.

Throws:

HttpClientException - If any error occurs.

add

void add(java.io.InputStream bytes)
  throws HttpClientException

Add raw binary to the result sequence.

Parameters:

bytes - The bytes representing the binary item to add to the result sequence.

Throws:

HttpClientException - If any error occurs.

add

void add(javax.xml.transform.Source src)
  throws HttpClientException

Add a document node to the result sequence.

Parameters:

src - The Source representing the document to add to the result sequence.

Throws:

HttpClientException - If any error occurs.

add

void add(HttpResponse response)
  throws HttpClientException

Add the http:response element to the result sequence. The implementation for a specific processor is supposed to call the method HttpResponse#makeResultElement(TreeBuilder) with a tree builder for the same processor. This must be added at the front of the sequence, always, even if it is called after other methods.

Parameters:

response - The response element to add to the result sequence.

Throws:

HttpClientException - If any error occurs.