anchor.diff:  defining a recursive structure (``Ingredient``s can consist of other ``Ingredient``s), and also dependencies between ``Ingredient``s.
   
   
  -
  -
  -pass:[<br/><br/>]
  -
   Both of these relationships can be maintained.  For example, we can set up a new dependency between ingredients:
   
   image::https://raw.githubusercontent.com/incodehq/radrace2015/master/images/240-ingredient-depend-upon-prompt.png[link="https://raw.githubusercontent.com/incodehq/radrace2015/master/images/240-ingredient-depend-upon-prompt.png"]
   
   
   
  -pass:[<br/><br/>]
  +pass:[<br/>]
   
   so that (in this case) the bearnaise sauce can only be ordered if steak has been ordered.
   
  
positive.code: 
  Having not worked with any of the other CASE tools, we took the opportunity to ask some of the other teams how they tackled testability.  We can't speak for all of them, but the Mendix team, for example, told us that they "have a tester" on the team.  Exploratory manual testing is essential, of course, but when we probed further it didn't seem that that tool had very much to assist with the development of automated tests.
  
  Another big difference, of course, is that an Apache Isis app is written in Java.  The computable.nl article in its introduction made the point: "The teams that scored the best in [previous] years, were always [those that] modeled and configured and not programmed."  This seems to be a false dichotomy... one can after all model in a programming language such as Java, indeed that is exactly what a framework such as Apache Isis is all about.  We had the opportunity after the competition to chat with the ThinkWise team, and - to be honest - we shared very similar philosophy that the domain model should sit in the middle of the app, and then the UI is - for the most part - a visual projection of that business domain.
  
  So the question isn't about modelling vs programming, it's about in what form do you want your model artifacts to be represented?  In the case of Apache Isis your model is represented in Java, following a number of simple http://isis.apache.org/cheat-sheet.html[programming model conventions].  (Not that it would necessarily gain you much, but) it would be feasible to take an Apache Isis application and use its domain model within a custom app built using Spring, for example.
  
negative.code: 
  === Ingredients and Suppliers
  
  The club administrator can also use the app to set up ``Ingredient``s with associated `Supplier` and `IngredientCategory`.  We loaded this fixture data from an https://github.com/incodehq/radrace2015/blob/master/fixture/src/main/java/domainapp/fixture/scenarios/spreadsheets/EventImport.xls[spreadsheet]; each row corresponded to a https://github.com/incodehq/radrace2015/blob/master/fixture/src/main/java/domainapp/fixture/scenarios/spreadsheets/EventImport.java[view model] which used injected services to actually https://github.com/incodehq/radrace2015/blob/master/fixture/src/main/java/domainapp/fixture/scenarios/spreadsheets/EventImport.java#L212[create] the entities.
  
  The "All Ingredients" menu item:
  
  image::https://raw.githubusercontent.com/incodehq/radrace2015/master/images/200-ingredients.png[link="https://raw.githubusercontent.com/incodehq/radrace2015/master/images/200-ingredients.png"]
  
  
  
  
  pass:[<br/>]
  
  returns a list of ``Ingredient``s that are imported from the fixture data spreadsheet:
  
  