Just another Nodetraveller

A Service

Default values are stored in liveInfo.xml

The liveInfoDir points to the install directory of liveInfo. This is used by the js liveInfo object. The cacheTTL node defines the default time in seconds to cache the service. This can be overridden by a service. The cssLink points to the location of the default css stylesheet. This can also be overridden by a service. Also overrideable by a service is the liveInfoContainer node. This defines the HTML that is displayed when results are shown. The [<infoname>][<opname>] is used as placeholders and is replaced by the serviceName and opName in the final output on a page eg googleSearch. The structure of this node can change but note that the event handlers, id and class names should be the same. You should be able to add new elements also.

The google service xml looks like this:

The name, description and link nodes are there for informational purposes about the service. On line 6 we can see that this service is set to cache for only 15 mins. The key, q, lr, start, maxresults, filter, safesearch and restrict nodes are google webservice parameters. If a service needs service specific config values, they can be defined here in the xml and the service will pick it up.

Now every service has at least one operation. Here we define one called search. Google's webservice also provides a spelling operation. If we wanted to, we would have another liveOperation node which defines the information needed for that operation. The important nodes here are the liveInfoOperationName and the client nodes. The liveInfoOperationName identifies the operation and is used by the liveInfoManager to load up the correct service operation. The client node has a liveInfoForm node which is where the form for the service is defined. To note here is the keypress event handler event for the element that is to trigger the liveInfo. This event can be used on other elements if the form has more than one element. The liveInfoJS node contains the javascript code to create the liveInfo js object. Any parameters or customisation is set here. See the Javascript section for more information. Finally the cssLink node defines the link to the stylesheet for this service.

It's possible that a form element is dynamic. For instance, a select element's options are loaded from the database. In this case, we can specify a method to call which will output the element. To do this we put the following in the relevant place. An example

When the service encounters the node, it calls the getDays method and inserts the return value in the form

The PHP

An abstract class called liveInfo defines the interface which any service must implement. It also provides some helper methods for outputting xml, debug info and caching methods. The constructor looks like this.

The Google webservice is a soap service. Besides the liveInfo abstract class, the liveInfo framework is supplied with two subclasses called rpcLiveInfo and soapLiveInfo. These subclasses include the required library for using XMLRPC or SOAP. So if your service uses XMLRPC or SOAP you should subclass one of these methods. If not, then you should just subclass the liveInfo class. Its important that you do this and call the parent constuctor (see line 5). Calling the parent constructor, loads the default liveInfo.xml then calling the initialise() method, loads the service's xml file initialising the object with the data in the xml file

When a request from a liveInfo page element, its the getLiveInfo that is called. If cache is needed we get a cache object by calling the getCache method, then we call the getSearch method via the cache object' call method. If a cache is not needed, then we would just call the getSearch method directly. Then the results are packaged for return. Note also debug data is also added if debug mode is on. The getSearch method sets up the SOAP call, contacts the webservice and passes the results to the renderResults method which returns them nicely formated into an unordered list.

The resulting document for a search for "news" looks like this : (debug mode turned off)

If there were no results, the liveInfoResult would be replaced by a liveInfoNoResult node. If there was a fault of some sort, then the liveInfoResult node would be replaced by a liveInfoFault node.

Debugging

If debugging is turned on, then liveInfo outputs the debug output that is received form the server to an element that is identified by the id of serviceName+opName+_liveInfoDebug giving (for wordpress search) wordpressSearch_liveInfoDebug. You can also do some direct checking by inserting the liveInfo url into your browser with the required parameters. For example, for wordpress, the url would be [path to liveInfo]/liveInfo/liveInfo.php?liveInfo=wordpress&opName=Search&s=rpc

Todo:

Streamline debug

Make install easier with less or ideally no editing of xml files needed