So far so good, but using this update on Windows you might experience severe performance regressions for XOR drawing (typically used for drawing “ghosts”). This hurts our products as any other product or Java graphic app doing similar operations. Whether it actually hurts on a given machine, it may be dependent on the video card and drivers that you have installed.

Sun’s release notes warn us about this potential regression (see the section New Direct3D Accelerated Rendering Pipeline for Microsoft Windows Platforms, Enabled by Default). Sun tends to call it a “limitation”, however they classified the following as a bug: “D3D: XOR rendering is extremely slow” (don’t hesitate to vote for it). Hence, there is some hope the issue will be solved in a future update. In the meantime, you can apply the easy workaround mentioned in Sun’ release notes:

“To disable the Direct3D Pipeline, pass the following property to the Java VM: -Dsun.java2d.d3d=false. Alternatively, set the J2D_D3D environment variable to ‘false’ prior to starting your application (or set it globally).”

See also this forum discussion: “Java 2D - Problem drawing in XORMode with JDK1.6 Update 10”.

What’s New

• ILOG JViews Graph Layout for Eclipse is an entirely new product that brings the full power of ILOG’s graph layout algorithms to help make your Eclipse-based diagrams more readable. Native integration is provided for Eclipse’s EMF, GMF and GEF frameworks.  If you are working with diagrams, and either deploying to the Eclipse Rich Client Platform or creating an Eclipse plug-in, you should consider this new product.
• ILOG JViews Diagrammer’s includes better and faster graph layout for many of the node, link, and label algorithms. You also now have the ability to compile symbols directly into Java code, yielding performance improvements up to 300%.
• ILOG JViews Gantt adds support for activities with multiple date attributes, thus allowing you to render intra-activity time intervals and milestones much easier. This feature can be used to render lead/lag time, planned vs. actual, and activity breaks. We also added the ability to hide the root row of the chart and have made improvements to our zoom-to-fit calculations.
• ILOG JViews Charts has significant performance improvements for line and area charts, and especially for large sets of summed and stacked charts. In addition, we have added anti-aliasing for labels and you can now use arbitrary graphic objects from the ILOG JViews Graphic Framework as decorations.
• ILOG JViews Maps features our new Google Maps integration that allows you to create thin-client AJAX applications in which Google Maps is overlaid with JViews maps and symbols. We have also included performance improvements when you use large raster data sets, GeoTIFF map import is now faster, and you can perform ESRI shape map filtering at load time. We have also improved our support for Web Map Service (WMS) servers.
• ILOG JViews TGO contains many performance improvements, especially related to display initialization and startup.
• All ILOG JViews products have been updated to support the latest AJAX frameworks:
  • JSF support has been updated from the reference implementation 1.1 to 1.2, and we also support alternate implementations, such as Apache MyFaces.
  • Facelets support has been added.
  • We have added support for the leading partial-page-refresh (PPR) AJAX JSF frameworks, such as IceSoft IceFaces, Apache Trinidad, and JBoss RichFaces. In IceFaces, we now support their Comet push technology which allows you to update your web displays asynchronously without a user request.
  • We have updated our support for JSR-168 portals, such as Apache Pluto and LifeRay.
  • ILOG JViews 8.5 is now compliant with the latest standards from the OpenAjax Alliance.

How to Participate

• Log in to ILOG’s dedicated beta site and download the beta software.
• Subscribe to updates from this site – during the beta period, we’ll regularly share guided presentations on specific beta-related topics.
• Report bugs or ask questions on our dedicated Beta forum.

Furthermore–and this is where it really gets rockin’–we’ve incorporated the Comet server push capability that ICEfaces supports.    Whenever the underlying data changes, ICEfaces will notify all of the clients to update themselves.   And this is done asynchronously…no need to poll or wait for new data to be reflected on the display.

One example of how this might be used is a collaborative scheduling application.   You can have many people in different locations open their web browser that contains an ILOG JViews Gantt display.   When one person interactively moves a bar in the Gantt to reschedule a task, all other users will immediately see the change.   Pretty cool, considering that this is using nothing more than Ajax on the client!    (Stay tuned for a demo…)

Just like we did previously to describe how to use the new Eclipse features in the Beta, we’ve now created a little exercise here that is focused on web display creation. It includes a short (8 minute) step-by-step video that show you how to install a set of tools and settings (Tomcat, Eclipse, JViews and ICEfaces) and then proceed to create a project.

This exercise needs you to download the Beta from our Labs website.

The Designer tools eased the user experience to create style sheets, attracting more and more customers to the CSS path. In JViews 8.0 came the symbol, a black box containing CSS that manages a complex graphic representation as a whole. The symbol interacts with its environment through “parameters”, just like a procedure call. A Symbol Editor offers a GUI to create the symbol in an interactive environment.

What we called “the toolchain” contains so far the Symbol Editor, the Diagrammer Designer, and the Dashboard Editor. This toolchain leverages on symbols to create high value diagrams and dashboards made with interactive symbols. Note that this toolchain was possible only because the symbols are interpreted on the fly by a runtime environment flexible enough to allow edit and use in the same session.

Now in JViews 8.5 we added in the toolchain the Symbol Compiler to return to the Java world. The compiler actually translates a symbol into a java class with the same behavior. The gain is obviously performance, but also flexibility (symbols as java classes can be edited and subclassed for advanced uses).

The loop is closed. JViews now provides a powerful development environment that eventually generates a java class representing a sophisticated graphical component, dynamically customizable through parameters and fully interactive.

ILOG has just started the beta program for JViews Graph Layout for Eclipse, a brand new product used to add powerful graph layout capabilities to pure Eclipse (GEF and GMF) applications.

Here is a link to a step-by-step exercise showing how to take an existing generic GMF modeler and quickly add JViews graph layouts to it. This exercise contains a plugin (with source code) for a generic GMF editor and a movie explaining how to enable graph layouts.

What’s New

ILOG JViews Graph Layout for Eclipse features a full range of graph layout algorithms that make diagram displays more readable; it is a native integration with Eclipse’s EMF, GMF and GEF.  If you are working with diagrams, and either deploying to the Eclipse Rich Client Platform or creating an Eclipse plug-in, you should consider this new product.

ILOG JViews Diagrammer’s Beta includes:

• Faster and better graph layout, for many of the node, link, and label algorithms.
• The ability to compile symbols directly into Java code, yielding improvements up to 300%.
• A new integration with the latest Ajax frameworks, such as IceFaces, RichFaces and Trinidad, shortening development time and lowering maintenance costs.

How to Participate

• Log in to ILOG’s dedicated beta site and download the beta software.
• Subscribe to updates from this site – during the beta period, we’ll regularly share guided presentations on specific beta-related topics.
• Report bugs or ask questions on our dedicated Beta forum.

   If you are an existing customer, please check your email for information about an exclusive webinar that we will conduct on Thursday of this week.  If you believe you should have received an email but did not, contact us at workshop-us@ilog.com .

    If you are not a customer, we will post more information here for you next week.

Gantt Filter Model Overview

ILOG JViews Gantt provides several filtering data model implementations. All filter models act as wrappers around an underlying data model that contains the “real data”. The purpose of a filter model is to provide an alternative subset or perspective on the data, while eliminating the overhead of data duplication. At the base of the hierarchy is the IlvFilterGanttModel class which is a thin wrapper class that, in fact, provides no filtering at all! All of the IlvFilterGanttModel methods simply delegate to the underlying model as their default behavior. In order to create an actual filter, it is necessary to subclass IlvFilterGanttModel and override appropriate methods to achieve the desired behavior. The IlvBasicFilterGanttModel subclass, which is built into the JViews Gantt library, does precisely this. It allows to set an arbitrary filtering function for activities and/or resources, which results in a subset view of the underlying data model. Usage of IlvBasicFilterGanttModel is illustrated in the Filtering Activities sample.

ILOG JViews Gantt provides another filter model in the Sorting Activities sample as source code. This is the SortGanttModel class, which generates an alternative ordering  of activities in the data model. The ordering is controlled by a customizable comparator function. The Sorting Activities sample shows the SortGanttModel being used to view activities ordered by name or by start time. However, the concept is completely general and can be extended to order activities by any criteria for which you can write a function. Notice though, that the SortGanttModel does not provide a subset view of the underlying data model, it merely provides an alternate perspective.

Drill Down Concepts

Now, we will look at the design of a filter model that allows us to drill-down and view only a portion of the activity hierarchy tree. The filter model will show us a subtree of the underlying data that is rooted at an arbitrary activity. Being very clever, we will call this implementation a SubtreeGanttModel. When designing a filter model (or any data model for that matter!) it is critical to ensure that client software “sees” a consistent view of the model state through the model’s api’s. For example, if a filter model provides an alternate perspective on the data, it is mandatory that all of the filter model’s methods provide the same perspective. The events fired by a data model are also part of its public api. All event listeners on the filter model must receive events that are also consistent with the model’s perspective of the data. In summary, there are three aspects to a model’s api that must be consistent among themselves:

1.  Accessor methods must provide a consistent perspective of the data.
2. Mutator methods must modify the model in a manner that is consistent with the data perspective.
3. Events fired by the model must be consistent with the data perspective.

Getting Started With Accessing Activities

Let’s start implementing our SubtreeGanttModel by subclassing IlvFilterGanttModel and overriding the methods necessary to access the subtree of activities. For now, we will ignore handling of events and other details that we will get to later. First, we create the basic class skeleton:

public class SubtreeGanttModel extends IlvFilterGanttModel {

  // The root activity of the subtree.
  private IlvActivity rootActivity;

  public SubtreeGanttModel() {
    this(null);
  }

  public SubtreeGanttModel(IlvGanttModel filteredModel) {
    super(filteredModel);
  }
}

The rootActivity field will hold the root of the subtree perspective. If the value is null, then the SubtreeGanttModel will appear to contain no activities. This is the same behavior as any Gantt data model that has a null root activity. Otherwise, the rootActivity field must be an activity contained in the underlying filteredModel. In this case, the SubtreeGanttModel will provide a subtree perspective that is based at this activity. Obviously, we must override the getRootActivity method like this:

public IlvActivity getRootActivity() {
  return rootActivity;
}

We will address overriding the setRootActivity method later. Next, let’s handle the contains(IlvHierarchyNode) method. This method is used to query whether an activity or a resource is a member of the data model. We are only modifying the perspective of the activities, so let’s factor this out into a separate helper method:

 public boolean contains(IlvHierarchyNode activityOrResource) {
    if (activityOrResource instanceof IlvActivity) {
      return containsActivity((IlvActivity) activityOrResource);
    } else {
      return super.contains(activityOrResource);
    }
  }

  private boolean containsActivity(IlvActivity activity) {
    // Check that the activity is a member of the filtered data model.
    IlvGanttModel filteredModel = getFilteredModel();
    if (filteredModel == null || !filteredModel.contains(activity)) {
      return false;
    }
    IlvActivity root = getRootActivity();
    if (root == null) {
      return false;
    }
    return activity == root
           // Use filtered model as slight optimization
           || IlvGanttModelUtil.isDescendant(filteredModel, root, activity);
  }

In this way, we only return true if the activity parameter is a member of the subtree defined by the rootActivity. We now need to override the two methods that traverse up the activity tree, from children to parents. These methods must be rewritten so that the traversal stops at the root of the subtree:

  public IlvActivity getParentActivity(IlvActivity activity) {
    if (activity == getRootActivity()) {
      return null;
    } else {
      return super.getParentActivity(activity);
    }
  }

  public int getParentActivityIndex(IlvActivity activity) {
    if (activity == getRootActivity()) {
      return -1;
    } else {
      return super.getParentActivityIndex(activity);
    }
  }

We do not need to override the methods that traverse down the activity tree because this behavior is unaltered in the SubtreeGanttModel. In the next part of this article series, I will detail how filtering of activities affects the filtering of constraints and reservations. We will also see how to finally write that crucial setRootActivity method. Stay tuned!