anchor.diff:  Like all web pages, this UI is generated at runtime, directly from the domain object itself.
   There are no controllers or HTML to write.
   
  -image::https://raw.github.com/apache/isis/master/adocs/documentation/src/main/asciidoc/pages/isis-in-pictures/images/isis-in-pictures/040-domain-entity.png[link="https://raw.github.com/apache/isis/master/adocs/documentation/src/main/asciidoc/pages/isis-in-pictures/images/isis-in-pictures/040-domain-entity.png"]
  +image::https://raw.githubusercontent.com/apache/isis/master/antora/components/toc/modules/ROOT/images/what-is-apache-isis/isis-in-pictures/040-domain-entity.png[link="https://raw.githubusercontent.com/apache/isis/master/antora/components/toc/modules/ROOT/images/what-is-apache-isis/isis-in-pictures/040-domain-entity.png"]
   
   In addition to the domain entity, Apache Isis allows layout metadata hints to be provided, for example to specify the grouping of properties, the positioning of those groups into columns, the association of actions (the buttons) with properties or collections, the icons on the buttons, and so on.
   This metadata can be specified either as annotations or in JSON form; the benefit of the latter is that it can be updated (and the UI redrawn) without restarting the app.
  
positive.code: These same fixture scripts can be reused within integration tests.
  For example, the code snippet below shows how the `FixtureScripts` service injected into an integration test can then be used to set up data:
  
  image::https://raw.github.com/apache/isis/master/adocs/documentation/src/main/asciidoc/pages/isis-in-pictures/images/isis-in-pictures/210-fixture-scripts.png[link="https://raw.github.com/apache/isis/master/adocs/documentation/src/main/asciidoc/pages/isis-in-pictures/images/isis-in-pictures/210-fixture-scripts.png"]
  
  The tests themselves are run in junit.
  While these are integration tests (so talking to a real database), they are no more complex than a regular unit test:
  
  image::https://raw.github.com/apache/isis/master/adocs/documentation/src/main/asciidoc/pages/isis-in-pictures/images/isis-in-pictures/220-testing-happy-case.png[link="https://raw.github.com/apache/isis/master/adocs/documentation/src/main/asciidoc/pages/isis-in-pictures/images/isis-in-pictures/220-testing-happy-case.png"]
  
  
  To simulate the business rules enforced by Apache Isis, the domain object can be "wrapped" in a proxy.
  For example, if using the Wicket viewer then Apache Isis will enforce the rule (implemented in the `ToDoItem` class itself) that a completed item cannot have the "completed" action invoked upon it.
  The wrapper simulates this by throwing an appropriate exception:
  
  image::https://raw.github.com/apache/isis/master/adocs/documentation/src/main/asciidoc/pages/isis-in-pictures/images/isis-in-pictures/230-testing-wrapper-factory.png[link="https://raw.github.com/apache/isis/master/adocs/documentation/src/main/asciidoc/pages/isis-in-pictures/images/isis-in-pictures/230-testing-wrapper-factory.png"]
  
  
  
  
negative.code: By default properties on domain entities are editable, meaning they can be changed directly.
  In the todoapp example, the `ToDoItem`'s description is one such editable property:
  
  image::https://raw.githubusercontent.com/apache/isis/master/antora/components/toc/modules/ROOT/images/what-is-apache-isis/isis-in-pictures/050-edit-property.png[link="https://raw.githubusercontent.com/apache/isis/master/antora/components/toc/modules/ROOT/images/what-is-apache-isis/isis-in-pictures/050-edit-property.png"]
  
  Note that some of the properties are read-only even in edit mode; individual properties can be made non-editable.
  It is also possible to make all properties disabled and thus enforce changes only through actions (below).
  