Obyx

Output

All flow-functions produce a result. The output element informs the flow-function as to which spaces the result should be placed. A flow-function may have multiple output declarations, and each one will receive it's own copy of the flow-function result.

It is important to remember that the default output (ie, if no output is declared) is space="immediate", which passes the result to the parent (or to stdout when the flow-function is the root element). Therefore, when results are to be discarded, an output of space="none" must be declared.

space attribute

• immediate* outputs to parent or stdout
• store outputs to a store (variable)
• file outputs to a file on the filesystem
• cookie outputs to a response-cookie if Obyx is being run as a cgi, otherwise it is ignored. The part of a cookie to be written to can be chosen by using the part attribute.
• error This is the catch/ exception mechanism of Obyx - the result will be the contents of the thrown error, and will be accessible from the store.
• http outputs to http response headers if Obyx is being run as a cgi, otherwise it is ignored.
• none the result is discarded
• namespace the result is to be used as a namespace signifier
• grammar the result is to be used as an xml grammar (either DTD or XML Schema are supported)

The following example shows an example of placing a result into a store. This store is then tested against the same data, and where you can see that it exists and is the same as the store.

<instruction>
	<output space="store" value="number" />
	<input value="1234321" />
</instruction>
<comparison operation="equal">
	<comparate space="store" value="number" />
	<comparate value="1234321" />
	<ontrue value="This number exists" />
	<onfalse value="This number doesn't exist" />
</comparison>

This number exists

scope attribute

store space (or variables) requires a scope, so that we know when a store is local to the document, or should belong to a higher document, or even be global. A global store is available to all functions within the process. Scope is only required for stores that do not have an xpath component; this is because the scope attribute deals solely with the (potential) creation of stores.

• branch* the store is available to this document and any functions called by this document.
• global the store is made available everywhere
• ancestor The store must already have been initialised by an ancestor, and the value will be overwritten.)

The following example shows setting up a store with global scope. (URL_TIMEOUT_SECS is a meta value used for url spaces and osi document evaluation).

<instruction note="set url timeouts">
	<output space="store" scope="global" value="URL_TIMEOUT_SECS" />
	<input value="30" />
</instruction>

The following example shows setting up a store with branch scope, and then calling a function that uses it.

<instruction note="initialise a callback. branch is default, so no need to declare it.">
	<output space="store" scope="branch" value="my_callback" />
	<input space="none" />
</instruction>
<instruction operation="function">
	<input space="file" value="example.ixml" />
	<input name="callback" value="my_callback" />
</instruction>
<s space="store" value="my_callback" release="true" />

you got the message, I hope

<instruction note="the example.ixml function used for the callback example, using ancestor.">
	<output space="store" scope="ancestor" context="parm" value="callback" />
	<input value="you got the message, I hope" />
</instruction>

The following example shows setting up a store globally. URL_TIMEOUT_SECS is a meta value used for url spaces and osi document evaluation

<instruction note="set url timeouts">
	<output space="store" scope="global" value="URL_TIMEOUT_SECS" />
	<input value="30" />
</instruction>

part attribute

This is only used when the space attribute is a cookie. There are four values: ('value', 'expires', 'domain', 'path') which refer to the different parts of a response cookie. By default it is the value of the cookie which is set. As well as the standard date format, the expires value recognises two helper settings: "persist" and "discard". Persist will set expiry one year hence, and discard will set expiry into the past, effectively asking the user-agent to delete the cookie.

<instruction>
	<output space="cookie" part="value" value="foo" />
	<input value="hello" />
</instruction>

Set-Cookie:foo=hello; path=/