37
edits
Changes
m
In understanding Umlaut, it's helpful to understand a bit about the nature of an OpenURL, including that an OpenURL is composed of several entities or groupings of metadata. Jeff Young's # [http://q6.oclc.org/2006/08/welcome_1.html Q6 blog[Request Setup and Environmental Context]] includes one good explanation of the six OpenURL entities. Two sets of classes are involved in dealing with OpenURLs in Umlaut. The ropenurl library is generally used # [[ServiceResponse data structures and generation]] -- Includes guide to parse OpenURLswriting your own services. However, Umlaut serializes OpenURLs to it's own classes--# [http://umlaut.rubyforge.org/api/files/app/models/request_rb.html Request[View architecture and control flow], to represent an incoming OpenURL request, and some constituent data in [http://umlaut.rubyforge.org/api/files/app/models/referent_rb.html Referrent], # [http://umlaut.rubyforge.org/api/files/app/models/referent_value_rb.html Referent Value[Background services], ] -- control and [http://umlaut.rubyforge.org/api/files/app/models/referrer_rb.html Referrer].view architectures for background services
link
To give you an overview of the technical architecture of umlaut[[Umlaut]], we will go through a typical Resolve request, identifying all the classes involved, and pointing to their api doc if possible.
OpenURLs are sent to the default index action of the [http://umlaut.rubyforge.org/api/files/app/controllers/resolve_controller_rb.html resolve controller].
In the resolve controller, a before filter method called init_processing is run to parse the OpenURL and set up the Umlaut request (or retrieve an existing request).
==OpenURL parsing and initial actionTechnical Overview Sections==
