anchor.diff:  application. We select `editor` as the name of the new MVC group. There are 5 new files generated using the
   default templates. Take special care of the last message; the files were created but this doesn't mean the application
   will be able to instantiate the MVC group at runtime. The final piece of the puzzle is letting the application know
  -that about this new MVC group, this is done by editing `Config.java`
  +about this new MVC group, this is done by editing `Config.java`
   
   [source,java,options="nowrap"]
   .griffon-app/conf/Config.java
  
positive.code: Besides the convoluted binding on the ``textArea``'s text property (unfortunately text is not a bound property) the other
  special pieces of code found in this class are the usages of the _parentView_ field. Notice the that the type is set to
  `ContainerView`, this means this View is aware that it's not a top level MVC group, that is, there will be another
  MVC group that will be responsible for instantiating `editor`, in this case is the `container` MVC group. A parent/child
  relationship is established between the two MVC group instances when this happens. More information about this
  relationship can be found at the link:/guide/latest/index.html#_mvc_mvc_group_relationships[guide, window="_blank"].
  
  
negative.code: include::{editor-swing-java}/griffon-app/views/editor/ContainerView.java[lines=16..-1]
  ----
  
  Here we find a `Window` object containing a `JMenuBar` and a tab container (a `JTabbedPane`) named _tabGroup_.
  This tab container is exposed to the outside world via a getter method; we'll see why it's done this way when the
  second MVC group comes into play. The View is also responsible for managing a `JFileChooser` that will be used to
  select files for reading. Notice the conditional enabling of the `save` action given the state of the `dirty` property
  