anchor.diff:  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
  +MVC group that is responsible for instantiating `editor`, in this case it 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"].
   
  
positive.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 the tab container (a `JTabbedPane`) dubbed _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
  
negative.code: 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
  about this new MVC group, this is done by editing `Config.java`
  
  [source,java,options="nowrap"]
  .griffon-app/conf/Config.java
  