200
edits
Changes
m
→The handle method
The heart of a typical service is in implementing the [http://umlaut.rubyforge.org/api/classes/Service.html#handle handle] method. When Umlaut wants a service to do it's thing, Umlaut will pass the request in, and it's up to the Service to do it's work.
The service can examine all metadata from the request, and even examine ServiceResponses generated by other services, and the status of other services in progress or finished. (See [http://umlaut.rubyforge.org/api/classes/Request.htmlRequest#dispatched_services ], Request#dispatched_servicesdispatched, Request#services_in_progress, etc.) The service can then enhance any metadata if desired (likely data in [http://umlaut.rubyforge.org/api/classes/Referent.html Referent], from Request#referent). The service can create one or more ServiceResponses. A ServiceResponse normally represents a discrete package of data that will be displayed on some part of the resolve menu. ServiceResponses should generally be created with the convenience method [http://umlaut.rubyforge.org/api/classes/Request.htmlRequest]#dispatched? add_service_response. The Service code is also responsible for registering a DispatchedService object with the completion state of the service. This should be done with the convenience method [http://umlaut.rubyforge.org/api/classes/Request.html Request]#dispatched]. If the service throws an uncaught exception, Umlaut itself will register a DispatchedService with status FailedFatal. But otherwise, the service is responsible for registering a completion status, or Umlaut may not realize the service is complete and continue running it over and over again, or reporting it as timed out. ====callback methods==== ====Alternate Service Tasks==== Services were originally designed to do one thing, as described above. However, it has been useful to use the service architecture to perform other 'tasks' too, basically other sorts of plug-ins. What plug-in 'task' a service will be called upon to perform depends on the task config property in services.yml, which defaults to 'standard' when empty. The other service task we have defined currently as 'link_out_filter'. A task:link_out_filter service will never have it's handle method called. Instead, it will have a [http://umlaut.rubyforge.org/api/classes/RequestService.htmlService#services_in_progress Request#services_in_progress]link_out_filter method defined, etcand called at the appropriate control point. Examples of link_out_filter services are ezproxy, and sfx_backchannel_record.)