Support Location module

Moved Geo support to separate issue #658996: Support Geo module.

I'm not an expert in the internals of Location, but I need to support this for a project I'm working on. Here are a few thoughts upon which I am currently cogitating. Guidance welcome.

Location is sorta kinda like CCK, but not really. You can pick and choose which fields are included in the locations for a content type, but only from a pre-defined set of them. The question then is do we treat location like cck and support each of these fields separately? Currently thinking hell no.

Location is sorta kinda like Taxonomy, but not really. Each location is stored in a separate database table and associated with nodes via a location ID. In principle you should be able to assign the same location to multiple nodes or users, but the UI doesn't seem to support this. You can also create locations independent of nodes or users, but again there's no UI for this. Unlike Taxonomy, Location seems to work on the assumption that you'll only - and always - save locations on a node_save() or user_save(). That means we can't just pass around ID numbers with getter and setter callbacks as I did with the taxonomy plugin (#649848: Support taxonomy (not content_taxonomy) fields), unless we want to deal with potential unanticipated consequences of having saved a location without a corresponding node or user save at the end of whatever we're doing. I think this practically forces us into using verbatim getter/setter callbacks.

You can also create locations independent of nodes or users

Seems I'm wrong about that. Location IDs seem to have a one-to-many relationship to node vids. Edit any location sub-field and the lid increments.

Spent a fortnight over-thinking the general problem of how to deal with complex fields, then noticed how Location token integration works and have adopted a similar approach.

Getter and setter callbacks for the 'locations' field work with the raw value of $node->locations, and this is also what is returned by the export callback. Import callback for the 'locations' field accepts an array of locations, array of location IDs, single location, or single location ID. In the latter two cases it assumes we want to update $node->locations[0]. Location IDs will be automatically expanded into location arrays using location_load_location(). Don't know why you would find this useful, but it was easy to do so what the hell.

Also have some psuedo-fields you can work with for convenience:

'location' works kinda like $node->location which location module just populates on node_load() from $node->locations[0]. Setter callback takes a location array and import callbacks additionally accept a location ID. These go into $node->locations[0] do not modify the real value of $node->location, as I'm lazy and can't see a reason why this would be useful (location.module ignores the value of $node->location on 'insert' and 'update' ops). You'll have to save the node and reload it for $node->location to update, or else manually copy $node->locations[0] yourself.

Location "sub-fields" are turned into pseudo-fields with the following names:

'location-name',
'location-street',
'location-additional',
'location-city',
'location-province',
'location-postal_code',
'location-country',
'location-latitude',
'location-longitude',
'location-source',
'location-is_primary',
'location-province_name',
'location-country_name',
'location-fax',
'location-phone'

Getter and export callbacks for these return an array of values. i.e. fieldtool_get('location-address', $node) in a node with two locations will return array($node->locations[0]['address'], $node->locations[1]['address']). Setter/import callbacks for these pseudo-fields are non-destructive; a value of array('1' => 'some string') will not destroy values in $node->locations[0]. The import callback will treat a scalar value as a single-value array.

The location ID field can't be updated in this way; this would be functionality with only harmful applications as far as I can see.

Seems to work for me. Feedback appreciated.

Committed.