Re: [ve-dev] Understanding this huge pile of code... ;-)

[Joe Winchester <WINCHEST@xxxxxxxxxx>]

>Suppose I have a visual layout that extends JPanel and has a BorderLayout
>set.  I then do the following:
>- Select button in the palette.
>- Drop it in the west region of the BorderLayout.
>Questions:
>- What actors (Java objects) will participate in selecting the button,
>providing the borderlayout assistance as my mouse moves over the panel,
>detecting the drop, hit testing the region of the border layout in which to
>drop the button, and actually performing the drop?

There is an EMF model behind the VE and it's good to work in a mode where you can see the serialized form of this.  To do this from the IDE that launched your Eclipse workspace (i.e. your development Eclipse) visit the launch configuration, enable tracing, and for the ve plugin select org.eclipse.ve.java.core and change debug/xmltext to true.  Then in the workspace that is running the VE visit the preferences page and a new checkbox should be there that lets you see the serialized model.

The reason for seeing the model is that you can see the objects that get created.  For the scenario you described let's start with just dropping a JPanel down and dragging it to have an initial size of 277,163.  I've simplified the model below but it will be something like this with two EMF instances.  These are for the JPanel and the Dimension for its size.  The Dimension is modeled within the method that initializes it (which is the same one that returns and creates the panel), and the panel points to it.

  <members xsi:type="javax.swing:JPanel" size="//@methods.0/@properties.0"/>
  <methods name="getJPanel" initializes="//@members.0" return="//@members.0">
    <properties xsi:type="java.awt:Dimension" initializationString="new java.awt.Dimension(227,163)"/>
  </methods>

All of the objects (the JPanel and the Dimension) inside the VE are instances of JavaObjectInstance.  This is an EMF instance whose metaobject is a JavaClass.  Every relationship on the JavaClass comes from a mixture of introspection and merging with override data, to build up a structure of what the shape of the class is - what properties it has and what relationships it has to other classes.  The size property is picked up through introspection.

Now you visit the property sheet and change the panel to BorderLayout

 <members xsi:type="javax.swing:JPanel" size="//@methods.0/@properties.0" layout="//@methods.0/@properties.1"/>
  <methods name="getJPanel" initializes="//@members.0" return="//@members.0">
    <properties xsi:type="java.awt:Dimension" initializationString="new java.awt.Dimension(227,163)"/>
    <properties xsi:type="java.awt:BorderLayout"/>
  </methods>

An instance of BorderLayout gets created in the model, and the panel points to it.  To follow the property sheet a good object to breakpoint inside is org.eclipse.ve.internal.java.core.BeanPropertyDescriptorAdapter which creates the cell editor and label provider.

Now you visit the palette and select a JButton.  The JButton itself is created but not yet added to anything, and as the user moves the mouse around the GUI or the tree GEF edit policies are responsible for generating the command that is going to add it to the model.  Good objects to debug are ContainerGraphicalEditPart, that delegates everything to helpers.  Look at ILayoutPolicyFactory and its implementors and find the one for Border, and trace through how when the layout property was altered on the ContainerGraphicalEditPart how the factory was involved.  BorderLayoutPolicyHelper is used quite a bit.

When the user releases the mouse the command is executed and the model updated.  The Button is not added to the jPanel method (in the current code pattern) and has its own method created for it that returns and initializes it

 <members xsi:type="javax.swing:JPanel" size="//@methods.0/@properties.0" layout="//@methods.0/@properties.1">
    <components component="//@members.1" constraint="//@methods.0/@properties.2"/>
  </members>
  <members xsi:type="javax.swing:JButton"/>
  <methods name="getJPanel" initializes="//@members.0" return="//@members.0">
    <properties xsi:type="java.awt:Dimension" initializationString="new java.awt.Dimension(227,163)"/>
    <properties xsi:type="java.awt:BorderLayout"/>
    <properties xsi:type="java.lang:String" initializationString="java.awt.BorderLayout.NORTH"/>
  </methods>
  <methods name="getJButton" initializes="//@members.1" return="//@members.1"/>

The JPanel to JButton is interesting because instead of the JPanel having a child that is an instance of JButton, it instead has a child object called components that is an instance of an intermediate object called ConstraintComponent.  This object points to the component (the "//@members.0 is the JButton" and the constraint is the second property which (cause it's zero indexed) is an instance of a String that is "java.awt.BorderLayout.NORTH".

>- On what source lines should I drop break points if I want to see this
>happen?

The GEF editpolicies within the edit parts.  So try with ContainerGraphicalEditPart and stop within its edit policies.

>- How do I set break points in the target VM's code so I can watch it do its
>thing?

This I think is described in the help.  If not it's on the VEP newsgroup in the thread "Debugging Java beans in Visual Editor"

>- What parts of this are subject to change in the 3.0 code base?

For the model I think biggest change I can think of is how we store the information to instantiate instances.  Right now we tend to store a single initializationString which is evaluated in a way that works OK in stand alone mode, e.g.
jPanel.setBackground(java.awt.Color.red);
but we have more situations now, especially with SWT and people writing their own code they want the VE to be able to work with, where the expressions reference other fields in the model, e.g.
composite.setBackground(display.getSystemColor(SWT.COLOR_RED));
as well as ad-hoc code that just executes methods on their visual instances that they want to see the result of.
There is a design doc for this that I believe Rich sent around the newsgroup a while back that may have been hard to follow initially, but hopefully when we get more stuck in to the development of this the ensuing discussions will make this clearer.

Best regards,

Joe