Difference between revisions of "View architecture and control flow"

Revision as of 22:18, 6 February 2008

Part of [Umlaut Technical Overview]

Accessing response data

So the main interesting thing your View code wants to do is access data from ServiceResponses. There are some convenience methods to deal with the somewhat complicated data structures easily. There are also some abstractions in place to try to preserve encapsulation and loose coupling between views, data, and the Service adaptor code responsible for creating the data and dealing with any idiosyncracies.

Views are almost always interested in dealing with responses on a type-by-type basis, for instance all of the 'fulltext' responses. View code will normally call the ResolveHelper method #get_service_type(service_type). The argument should be the string name of the particular ServiceTypeValue type you are interested in--views are almost always interested in dealing with responses on a type-by-type basis. This will return an array of ServiceType join objects. But this is kind of tricky to deal with.

What you really want is just the collection of key/value properties according to the standard conventions for keys and values in a ServiceType. (See the documentation of conventions [http://umlaut.rubyforge.org/api/classes/ServiceResponse.html ServiceResponse ).

You can get that by calling #view_data on each ServiceType returned. That will return a Hash-like object with those keys and values. "Hash-like" because it may or may not be an actual Hash--in the simplest case, it'll actually be a ServiceResponse, but it'll be something that responds to [] to get the keys and values.

Now the View code can use []on these 'view data' objects to get any properties of interest. We will discuss later how the control chain actually gives Services several points of intervention to customize this view_data dictionary.

When the view code wants to make a link out to that response data (ie, let the user click on the fulltext link to go view the fulltext, it should generate a link to the LinkRouter controller, using the ServiceType id (not the ServiceResponse id) as a parameter. All links are sent back through Umlaut, rather than direct to target, to links to be modified or generated at the point of click (see link_out_filters on the Services page), and to allow the possibility of Umlaut clickthrough statistics.

For example:

service_type_obj
view_data = service_type_obj.view_data
<%= link_to view_data[:display_text], {:controller=>'link_router', :id=>service_type_obj.id}, 'target'=>"_blank" %>