For most yFiles FLEX applications using a yFiles Java server component, it is recommended to use the native GraphML extension of yFiles FLEX.

To use the native GraphML extension of yFiles FLEX, no special configuration is needed on the client. A plain RoundtripHandler can be used for communication with the server. If a default GraphRoundtripSupport instance is used for reading and writing the graph on the server, the yFiles FLEX native GraphML format will be correctly parsed on the server.

In order to manipulate yFiles FLEX styles, labels and label models on a yFiles Java server easily, the following prerequisites have to be met:

For details on reading, writing and accessing yFiles FLEX client style, label and label model data on a yFiles Java server, pleae see the section called “Manipulating yFiles FLEX Styles, Labels, and Label Models”

It is not recommended to use the yFiles for Java GraphML extension to transfer data between client and server.

There are, however, use cases where one needs a yFiles for Java compatible graph with visual features:

For these case it is recommended to use Flex native GraphML for the data transfer to the client and create a Graph2D exclusively for the export.

If the yFiles Java GraphML format is chosen for a yFiles FLEX application because the visual properties offered by the default yFiles Java realizers seem sufficient, note that once any additional visual properties are required for the application that are not supported by the default realizers, it will be harder to implement these additional properties using this approach.

No matter which server technology is used, it will be easier to add custom visual appearances to a yFiles FLEX application if the yFiles FLEX native GraphML format is used instead of the yFiles Java GraphML extension. However, if the Java application uses only the default realizer implementations provided by yFiles for Java or if the (de)serialization for custom realizers has already been implemented using custom realizer serializers, using the yFiles for Java compatibility features of yFiles FLEX allows to migrate the graphical appearance of the diagrams to the client without much effort.

The JavaCompatDemo included in the yFiles FLEX distribution shows how a Graph2D instance that uses arbitrarily configured default and custom yFiles for Java realizers can be displayed with a yFiles FLEX client.

In order to enable reading and writing of the yFiles Java GraphML extension, class JavaCompatGraphMLIOHandler is used. Please see API Excerpt 4.3, “Using a GraphMLIOHandler for reading and writing yFiles Java GraphML data” for details on using JavaCompatGraphMLIOHandler.

For backward compatibility reasons, there are two modes of the JavaCompatGraphMLIOHandler. The mode is determined by a boolean value passed to the Constructor. For best possible compatibility with the yFiles Java GraphML format, true should be passed to the Constructor. This will cause the I/O handler to use style implementations that were created specifically for compatibility with yFiles Java. Table 6.1, “yFiles Java compatibility styles” lists the mapping from yFiles Java realizers to yFiles FLEX styles, depending on the mode of the JavaCompatGraphMLIOHandler. If a yFiles Java realizer is parsed on the client, the corresponding style listed in the table will be created.

Table 6.1. yFiles Java compatibility styles

yFiles Java realizer	yFiles Flex style (useJavaStyles=true)	yFiles Flex style (useJavaStyles=false)
ShapeNodeRealizer	JavaShapeNodeStyle	ShapeNodeStyle
ImageNodeRealizer	JavaImageNodeStyle	ImageNodeStyle
PolyLineEdgeRealizer	PolylineEdgeStyle
ProxyShapeNodeRealizer	There are no corresponding proxy node styles in yFiles FLEX. Instead, the client's ProxyShapeNodeRealizerSerializer tries to find a suitable realizer serializer for the currently active realizer of the proxy realizer and delegates the actual parsing to that realizer serializer.
ProxyAutoBoundsNodeRealizer
GroupNodeRealizer	JavaGroupNodeStyle

The client library's AbstractJavaNodeStyle corresponds to the abstract NodeRealizer in yFiles Java.

GenericNodeRealizer

Another abstract style class, the JavaGenericNodeStyle faciliates transferring GenericNodeRealizer to yFiles Flex styles. For each GenericNodeRealizer configuration a subclass of JavaGenericNodeStyle and JavaGenericNodeStyleRenderer has to be created.

The custom rendering implementations have to be implemented in a subclass of JavaGenericNodeStyleRenderer. Table 6.2, “JavaGenericNodeStyleRenderer methods and the corresponding java implementations.” shows which Flex methods correspond to the GenericNodeRealizer implementations. Generally, it is sufficient to refactor the Java methods to Flex / ActionScript.

Table 6.2. JavaGenericNodeStyleRenderer methods and the corresponding java implementations.

Purpose	Java implementation	Flex implementation
Rendering	GenericNodeRealizer.Painter.paintNode()	paintNode()
Hit testing	GenericNodeRealizer.ContainsTest.contains()	isHit()
Intersection	GenericNodeRealizer.IntersectionTest.findIntersection()	getIntersection()
Bounds calculation	GenericNodeRealizer.UnionRectCalculator.calcUnionRect()	calculateBounds()

As GenericNodeRealizers are serialized only with their configuration name, the JavaGenericNodeRealizerSerializer searches for the configuration names in its configuration map for appropriate styles. Thus, when initializing this serializer/deserializer, appropriate styles have to be mapped to their corresponding styles.

Example 6.2. Initializing the JavaGenericNodeRealizerSerializer

// Add GenericNodeRealizer configurations. JavaBevelNodeStyle and 
// FloatingNodeStyle are subclasses of JavaGenericNodeStyle.
JavaGenericNodeRealizerSerializer.instance.addConfiguration(
    "Bevel", new JavaBevelNodeStyle());
JavaGenericNodeRealizerSerializer.instance.addConfiguration(
    "Floating", new FloatingNodeStyle());

The configuration property will be set automatically to the serialized configuration name for styles which are deserialized from GraphML. Styles which are created on the client must have their configuration property set to a valid configuration name in order to get serialized properly. If that configuration is not in the serializer's configuration map, it will be stored there automatically if such a style is serialized.

A special implementation of JavaGenericNodeStyle is the JavaGenericNodeStyleWrapper. This implementation can wrap an existing node style into a generic node style. This class can be used to handle GenericNodeRealizer which can be represented by an existing node style, e.g. a Realizer which uses a BevelNodePainter can be emulated with a BevelNodeStyle. It is possible to use this class without subclassing it. However, in some cases the style's properties correspond to some realizer related properties. For example: The BevelNodeStyle's color property has to be set depending on the fillColor property of the realizer. In this case, one has to subclass JavaGenericNodeStyleWrapper and override the fillColor setter to set the color property of the wrapped BevelNodeStyle, too. Usually, it is not necessary to write a custom renderer, however.

Example 6.3. Wrapping a BevelNodeStyle in a JavaGenericNodeStyleWrapper

public class JavaBevelNodeStyle extends JavaGenericNodeStyleWrapper {	
  // Creates a new instance.
  // If no style is provided, then a new one will be created by createStyle().
  // If no renderer is provided, a new instance of 
  // JavaGenericNodeStyleWrapperRenderer will be used.
  public function JavaBevelNodeStyle(style:BevelNodeStyle=null,
                                     renderer:JavaNodeStyleRenderer=null) {
    super(style, renderer);
  }
  // Creates a new instance of the wrapped style.
  protected override function createStyle():INodeStyle {
    var style:BevelNodeStyle = new BevelNodeStyle();
    style.radius = 5;
    return style;
  }
  // Delegates setting the fillColor to the wrapped style.
  public override function set fillColor(value:SolidColor):void {
    BevelNodeStyle(wrapped).color = value.color;
    super.fillColor = value;
  }
  // Creates a copy of this style.
  protected override function createClone():AbstractJavaNodeStyle {
    return new JavaBevelNodeStyle(wrapped.clone() as BevelNodeStyle, 
                                  styleRenderer as JavaNodeStyleRenderer);
  }
}