MSC Trial 6

Ken Webb 2010-05-14T17:52:17Z

In this Malleable Software Challenge (MSC) trial, I will run an existing Xholon application, and will then add two new features while it's running.

Contents


Specifically, I will add the following two features to the MeTTTa game:

This is what the application looks like before the new features are added.

And here's what it looks like after they are pasted in at runtime.

Visual comparison of the structural and wiring changes

A Xholon app can export its composite structure to FreeMind (.mm) mind-mapping format. XMind can read that format, and does a good job of showing the containment structure of the Xholon nodes and the port connections between nodes. XMind produced the following before and after diagrams by reading and displaying the unedited FreeMind .mm file. The blue arrows in each diagram show the wiring changes. For example, it's easy to see that the nine buttons in the GridLayout have been rewired to reference the new ScoreControlnode rather than the original MeTTTaController.

Before the new features were added.

After the new features were added.

Random Move button

A random move button can be added by pasting in the following XML as the last child of the VBox component.

<_-.forest>
  <Strut Height="10"/>
  <JButton Text="Random Move" ActionCommand="doyourthing" Background="RED">
    <RandomMoveControlnode/>
  </JButton>
</_-.forest>

This is the code for the RandomMoveControlnode.

public class RandomMoveControlnode extends Xholon {
    
    /*
     * @see org.primordion.xholon.base.Xholon#postConfigure()
     */
    public void postConfigure() {
        // get the controller that the parent JButton references
        IXholon controller = getParentNode().getPort(0);
        // have the JButton reference this Controlnode instead of the Controller
        getParentNode().setPort(0, this);
        // remove self from the GUI subtree
        removeChild();
        // append self as part of the Controller subtree
        appendChild(controller);
    }
    
    /*
     * @see org.primordion.xholon.base.Xholon#processReceivedMessage(org.primordion.xholon.base.IMessage)
     */
    public void processReceivedMessage(IMessage msg)
    {
        makeRandomMove();
    }
    
    /**
     * Make a random move.
     * For now, it just gets the next unoccupied position.
     */
    private void makeRandomMove() {
        MeTTTaModel model = ((MeTTTaController)getParentNode()).getModel();
        for (int i = 0; i < 9; i++) {
            if (!model.isPlayed(i)) {
                getParentNode().sendMessage(ISwingEntity.SWIG_ACTION_EVENT, "select" + i, this);
                break;
            }
        }
    }
    
}

Score mini-app

The Score mini-app is added at runtime by pasting the following XML as a last child of MeTTTaView instance. Note that an additional stylist was later pasted in to produce the blue labels, the orange background for the input fields, and the increased font sizes, that are apparent in the above after image.

<JFrame Title="Player">
  <JPanel>
    <VBox>
      <HBox>
        <JLabel Text="Name"/>
        <JTextField Columns="10"/>
      </HBox>
      <Strut Height="10"/>
      <HBox>
        <JLabel Text="City"/>
        <JTextField Columns="10"/>
      </HBox>
      <Strut Height="10"/>
      <HBox>
        <JLabel Text="Country"/>
        <JTextField Columns="10"/>
      </HBox>
      <Strut Height="10"/>
      <JButton Text="Submit" ActionCommand="submit">
        <ScoreControlnode/>
        <ScoreModelnode/>
      </JButton>
      <Strut Height="10"/>
      <HBox roleName = "Score">
        <JLabel Text="Score"/>
        <JTextField Columns="5" Editable="false"/>
      </HBox>
    </VBox>
  </JPanel>
</JFrame>

Discussion

No changes were made to existing Java source code or existing XML files when implementing these two new features. The original software can continue to run exactly as before. The new features must coexist with the structure already in place, and can only take advantage of information pathways that are publicly accessible. This places some limits on how the new features are implemented.

Both new features include a Controlnode Java class that is configured as a child of a JButton. During post-configuration, the Controlnode gathers information from its JButton parent and the GUI that the JButton is part of. The Controlnode then locates the Controller that the JButton references, changes that JButton reference to point to itself, and moves itself to become a child of that Controller.

The new Score feature rewires many of the existing buttons to reference itself. In this way, the ScoreControlnode gets first crack at some of the GUI events, before passing them on to the main Controller.

The basic approach requires that new features have some knowledge of the structure of the environment they are being injected into. They are able to follow existing pathways to locate other components, and are able to move themselves to the most convenient location in the existing tree. They are able to do this without compromising existing functionality. The process can be repeated multiple times for multiple new features.

return to main page