dingproject/ting — pull request #19 by kasperg (2011-10-23 21:04:47+00:00)
Title: Updated Ting object, collection and search result information

There are quite a few changes here.

The information shown for objects, collections and search results have been updated as requested [#1568](https://libraryding.lighthouseapp.com/projects/27862/tickets/1568-alle-felter-i-dkabm-skal-vises-p-materialevisningssiden#ticket-1568-28).

**More important**
During the implementation I discussed how to clean up the current approach to templating Ting objects where some data is processed [right after retrieval in ting.client.inc](https://github.com/dingproject/ting/blob/master/ting.client.inc#L375) and other is handled [directly in the template layer](https://github.com/dingproject/ting/blob/master/ting_object.tpl.php#L73) with @mikl.

Based on this I wrote two central functions to extract data from [objects](https://github.com/kasperg/ting/blob/1568-ting-information/ting.theme.inc#L348) and [collections](https://github.com/kasperg/ting/blob/1568-ting-information/ting.theme.inc#L527) and make them more easily available. [Generating lists of object information is structured around this](https://github.com/kasperg/ting/commit/98a98db97f45fa1b9980b9d4fe49360c58e16ac6#L5R172).

The goal is to deprecate `ting_*_add_information()` as well as the properties added to objects in this function and clean up the template code.

Consequently all templates which use ting objects or collections would have to be cleaned up - like [this](https://github.com/kasperg/ting/commit/98a98db97f45fa1b9980b9d4fe49360c58e16ac6#diff-2). Basicly no more object attribute access - more usabile variables. (I imagine leaving `ting_*_add_information()` until 1.8.0 to give people a little time to adjust their templates).

During conversion of the existing core codebase I ran into situations where this approach didn't not seem right.

The new approach is very much geared towards template files where I think it works well. However we use Ting properties in other situations as well and here the new processing makes things less elegant ([example](https://github.com/kasperg/ting/commit/98a98db97f45fa1b9980b9d4fe49360c58e16ac6#L1L242)). It's probably also slower as the same object may be processed multiple times.

Another option would be to move the processing from `ting_*_preprocess()` to somewhere within `ting.client.inc`. This would extend the OOP approach from 1.6.x and back but perhaps make it easier to process data and move it from `$object->record['attribute']['namespace'][0]` to `$object->attribute`.

What do you think, @cableman and @mikl?