anchor.diff:  === Owner search page
   
   The OwnerSearchPage is a SimpleSearchPage. Why simple? Because the objects displayed are not a reduced version
  -but the business entities itself. For complex entities with lots of depending objects it's a good idea to
  +but the business entities itself. For complex entities with lots of depending or rerferenced objects it's a good idea to
   have a search entitiy (a view) of the complex entitiy. So you load only a small part of the data. Then when
   the user wants to display a single entity in its full beauty you have to reload the entity with all depending
   objects. Obviously for that you have to have two classes and the SearchPage needs exactly these two classes
  
positive.code: before setting it to the pet. Then send it to the backend for persisting. The pet would still
  referered as the original type.
  
  NOTE: This behavior is always important to remember. It stands for codes but also for views. Actually it's
  the main behavior of views. Views are normally are parts of normal entities (selected non-list fields). Codes are like 
  'views on themself' (this is also the reason why the Code interface overrides the generic of the
  View interface).
  
  Codes have another speciality. Their initial values can be specified. This can happen in two ways.
  The first one is to have a csv - file with the same name in the same package as the Code class
  
negative.code: == Pet Clinic
  
  The pet clinic demo application was published by the spring framework. It is probably meant to be
  a distant relative to Sun's pet store. The pet store was abonded by Sun and Oracle long ago but the
  