Re: Action vs Controller

Royan <romayankin@gmail.com> writes:


  In Java, often, a UI object is used instead of MVC.

      ?The first Swing prototype followed a traditional MVC [...]
      We quickly discovered that this split didn't work well [...]
      So we collapsed these two entities into a single UI object [...]?

http://java.sun.com/products/jfc/tsc/articles/architecture/index.html

  In my own GUI applications, I am now using objects I call
  ?components?. By coincidence, these components often indeed
  also are objects of a subclass of ?javax.swing.JComponent?.

  (The rest of this post contains my own ideas about how I plan
  to construct my GUI applications. It might not be directly
  related to your question.)

  Each component can play all three rDles, i.e., model, view and
  controller.

  This sound like a big lump (i.e., bad style), but because each
  component has a clearly restricted responsibility, it will not
  get so large that this becomes a problem.

  ?Model? here means only ?application? model - any large
  calculation or data services are rolled out into service
  objectes (akin to a ?domain model? or ?implementation layer?).

  The application then is a tree of components, which only
  communicate via the tree connections.

  A component is an object controlling an area of a
  graphical user interface, like a command button or a window.
  (A degenerate component might also be an ?invisible?
  component, i.e., a simple object.)

  An application usually has multiple components, often nested in
  the form of a tree.

  A window (which is a component), for example, might have an
  upper part with a list (which is a component) and a lower part
  with a log console (which is a component).

                      window
                     component
                        /\
                       / \
                      / \
                     / \
                    / \
                 table console
               component component

       .---------------------------------.
       | window component |
       | .-----------------------------. |
       | | table component | |
       | | | |
       | | | |
       | | | |
       | '-----------------------------' |
       | .-----------------------------. |
       | | console component | |
       | | | |
       | | | |
       | | | |
       | '-----------------------------' |
       '---------------------------------'

  Now, for example, consider the question: How does the table
  component request some text to be logged onto the console
  component?

  I do not want the table component to be aware of the console
  component. This would make it more difficult to reuse the
  table component in other contexts without a console component
  or to add or remove the table component or the console
  component independently of other components. (If you do not
  accept this reason, I also might refer to Demeter's law.)

  So, instead of directly accessing the console component, the
  table component "escalates" a log-report to the window
  component, which is its container. The window component then
  knows that it has a "log-report-handler" (i.e., the console
  component), and then delegates the log-request to the console
  component.

  Thus, the application component structure I made up recently is
  to build an application as a tree of components which obey
  Demeter's law and therefore only communicate via the /edges/
  of this component tree, i.e., each component communicates only
  with its direct container or one of its direct containees.

  A common special case are several components sharing a single
  model. Then, I want a common container component of these two
  components to be (or hold) the model. For example,

                      window (and model for "view 0" and "view 1")
                        /\
                       / \
                      / \
                     / \
                    / \
                 view 0 view 1

       .---------------------------------.
       | window |
       | .-----------------------------. |
       | | view 0 | |
       | | | |
       | | | |
       | | | |
       | '-----------------------------' |
       | .-----------------------------. |
       | | view 1 | |
       | | | |
       | | | |
       | | | |
       | '-----------------------------' |
       '---------------------------------'

  Here, the window doubles as the model for its subcomponents,
  when they both need to refer to common data. (The observer
  relation might hold between any two components of an application,
  but has to be initiated via the edges of the tree.)

  The layout of an application might be changed at runtime by
  adding components to a container component. When this happens,
  some requirements will be checked: A certain container might
  only accept components implementing certain operations and the
  components might require its container to implement certain
  models for it.

  The tree structure means that each component (except the root
  component) has a single container component. This container
  component and the contained components (the ?containees? of a
  component) represents the rest of the application to the
  contained component. So, by Demeter's Law, each component can
  only see one step in each direction.

  Whenever a component needs something to be done it can not do
  itself, it will request this from its direct container or from
  one of its containees.

  When a container receives a request from one of its directly
  contained subcomponents (i.e., from one of its containees), it
  might handle it or it might delegate it to another of its
  containees or its container (which I call ?escalation?).

  When the root component receives a request it can not handle,
  it might report this as an error or silently drop the request,
  depending on what is most useful or appropriate in this
  application. (For example, when the ?console component? is
  removed from the above application example,
  console-log-requests could be dropped silently, so the
  application will still run, but not have a console anymore.
  Or, the root component might hold a ?console model? and add
  the messages to this model, so that they will all become
  visible when a console component is added again.)

  A component deep down in the tree might need to know the
  ?current directory? of the application, so it will ask its
  container:

this.container.getEnv( "cd" );

  If the container does not have an environment variable ?cd?,
  it will escalate the request to its own container:

Object getEnv( name )
{ if( this.env.contains( name ))return this.env.get( name );
  else return this.container.getEnv( name ); }

  Or, if a component does not have an own environment storage
  itself, it will immediatly escalate:

Object getEnv( name )
{ return this.container.getEnv( name ); }