So you have installed Canyon, got it running beautifully, but now you have a use case that is not quite sitting correctly with the straight forward mapping of the example, where you have one file per class. In these cases you have the option of creating your own PropertyAccessor.

The property accessor is one of the key features of Canyon that enable it to break out of the strictly rigid file/class mapping. By creating your own accessor you can override the default behaviour so that Canyon fits into your existing model, rather than changing your data to fit the class/file model.

We can use the Getting Started example as a starting point. In the example we had the concept of a manager. For ease of the example we had a separate file for manager objects. In reality this is unlikely. It is more likely that the manger will be in the employee file with some additional attribute to signify that he/she is a manager. By overriding the default accessor you can enable Canyon to allow multiple classes to be present in the same file. Lets solve that problem now.

One way to solve the problem is to approach the data in an OO fashion and intercept the employee call. By doing this we could interrogate the collection, and pull out the employee that is a manager and add it directly to the manager attribute. Lets see how we do it. Steps

1. Create a new class that implements the PropertyAccessor interface
2. Add the accessor attribute to the employee property in the shop mapping file
3. Remove the Manager mapping from the shop mapping file
4. Done!

The PropertyAccessor interface is fairly straight forward. It is responsible for actually assigning values to object attributes. The diagram below shows an implementation.

Notice that the value being passed in will be of the type declared in the mapping file, i.e a primitive property, an object, a set, or a collection (list).

This is striaght forward, and you will be assisted by the DTD

Remove redundant mapping

Also note that the Manager object has been removed from the mapping. This will stop Canyon from trying to load a manager object and potentially overwriting the work our accessor has done.