Introducing XGrid – a toolkit agnostic Grid control and component


Today I am happy being able to talk for the first time about a new component we’ve been developing for quite some time.

Before going into technical details, I’d like to point out that the development of features currently available has been sponsored by ITBH who agreed to have all sources released under the Apache license Version 2.0, that allows free usage in commercial products as long as the license terms are respected.

What is XGrid

XGrid is a feature rich Grid-Control, that can be set up using an imperative language like Java, but also by an EMF model in declarative fashion. In the current version, XGrid comes with built-in features like filtering or sorting and we are looking for funding of further developement (e.g. PDF export?). If you are interested, please contact us by email.

grid-total

Where do I get it from

XGrid is developed in a public github-repository and we are using the github infrastructure for bugtracking and documentation.

In case you miss a feature, please file a ticket and maybe consider, if you can support the development by funding it like ITBH did.

The XGrid design

At the root, XGrid is nothing more but a set of interfaces completely agnostic to the underlying UI toolkit, so it is possible, to use the same configuration and API regardless if you are developing an SWT, JavaFX, … application. At the moment, the only implementation of the XGrid API is for SWT, based on the excellent Nebula Grid control, that BestSolution.at has been maintaining for many years.

XGrid follows two key design patterns: On the one hand, @FunctionalInterface types are accepted almost everywhere in the API and on the other hand, Java8 features should be integrated including for example type annotations for NullAnalysis.

Sample usage

You are able to use XGrid by using its java API

public abstract class MyPersonGrid {

  public void setup() {
    XGridTable<Person> t = createControl();

    {
      XGridColumn<Person, String> c = t.createColumn("firstname", 
        p -> p.getFirstname());
      c.labelProperty().set("Firstname");
    }

    {
      XGridColumn<Person, String> c = t.createColumn("lastname", 
        p -> p.getLastname());
      c.labelProperty().set("Lastname");
    }

    {
      DateFormat f = DateFormat.getDateInstance();
      XGridColumn<Person, Date> c = t.createColumn("birthday", 
        p -> p.getBirthdate());
      c.textFunctionProperty().set((p,b) -> f.format(b));
      c.labelProperty().set("Birthday");
    }

    t.contentProviderProperty().set(
      new ListGridContentProvider<Person>(getPersonList()));
  }

  protected abstract XGridTable<Person> createControl();
}

public class MySWTPersonGrid extends MyPersonGrid {
  protected XGridTable<Person> createControl() {
    return new SWTGridTable<>(s, 
      SWT.BORDER | SWT.H_SCROLL | SWT.V_SCROLL);
  }
}

Like in day to day work, we often see that setting up controls like a grid based on Java is very cumbersome, and if you for example want to display different configurations based for example on user privileges, your code gets very complex quickly and maintainances becomes much more difficult.

Due to this, XGrid comes with an optional component that allows you to configure a grid instance by an EMF model, bringing the additional benefit of being able to load the application model from anywhere. So you can even update your XGrid component without deploying a new version of your application. Simply put the configurations on a remote server and fetch them from there.

Setting up a grid based on a configuration is nothing more than

public abstract class MyPersonGrid {
   URL configUrl = ....;

   private MGridConfigurationSet getConfig() {
     Resource resourceModel = new XMIResourceImpl();
     try(InputStream in = url.openStream()) {
       resourceModel.load(in, null);
       MGrid config = (MGrid) resourceModel.getContents().get(0);
       return config.getDefaultConfiguration();
     } catch(IOException e) {
       throw new RuntimeException(e);
     }
   }

   public void setup() {
     XGridTable<Person> t = createControl();
     MGridConfigurationSet c = getConfig();
     EmfGridTableConfigurator.configure(t, c);
   }
}

public class MySWTPersonGrid extends MyPersonGrid {
  protected XGridTable<Person> createControl() {
    return new SWTGridTable<>(s, 
      SWT.BORDER | SWT.H_SCROLL | SWT.V_SCROLL);
  }
}

What is XGridComponent

While XGrid is a pure Grid-Control, XGridComponent is a higher level element that collects the low-level features of XGrid and allows them to be integrated into a framework like Eclipse 4, where for example the grid selection is published automatically by an ESelectionService and the IEventBroker.

Besides this, we put a lot of attention on remaining framework neutral. Because of this, the XGridComponent implementation does not have any framework dependencies and expects itself to be configured through a dependency injection (DI) framework.

By default we ship an integration for e4, that can be used like this in your application model:

<application:Application>
<!-- .... -->
  <children xsi:type="basic:PartStack">
    <children xsi:type="basic:Part" 
      contributionURI="bundleclass://at.bestsolution.framework.grid.component/at.bestsolution.framework.grid.component.XGridTableComponent">
      <persistedState 
        key="xgrid.configuration" 
        value="emf-resource:platform:/plugin/at.bestsolution.framework.grid.e4.sample/config/sampleConfig.xmi"/>
      <persistedState 
        key="xgrid.content" 
        value="sample:platform:/plugin/at.bestsolution.framework.grid.e4.sample/sampledata/sampleData.xmi"/>
    </children>
  </children>
<!-- .... -->
</application:Application>

What’s next?

As already pointed out, the initial development of XGrid was funded by ITBH and they deserve all our respect for funding such a useful component.

At the moment, we are looking for additional funding for XGrid, allowing us to add additional, cool features like the ones below:

  • Editing support
  • XGrid-SWT is already fast but speed could be improved tremendously
    by using the Grids visibility feature
  • ODF, Excel & PDF export
  • JavaFX support

Just drop a note if you are interested in one of these or have further ideas on XGrid – we are looking forward to extend/adapt XGrid for you!

Advertisement
This entry was posted in Eclipse. Bookmark the permalink.

12 Responses to Introducing XGrid – a toolkit agnostic Grid control and component

  1. Hallvard Trætteberg says:

    I’m curious about the architecture, let me see if I understand this correctly: XGrid itself is not modelled, but defined by a Java API, that includes lots of configuration options, including column descriptors. Then you also have an EMF model of the configuration, that the EmfGridTableConfigurator is able to “inject” into an XGrid instance, presumably using the Java API. Is this correct?

    Perhaps you remember the Toolkit Model that I contributed to E4 (and that I “gave up” due to the disagreements with XWT)? A TM instance was toolkit independent, and could be rendered as an SWT widget tree. You approach is similar, in that from a model instance (the configuration), you create Java objects using an API. However, in TM I created the whole widget tree, while you configure an existing object structure. To create the TM SWT renderer, I wrote a DSL describing the mapping from model to SWT, from which I generated most of the rendering code.

    Is the Java API and EmfGridTableConfigurator all written by hand? I can imagine it should be possible to write a DSL or similar that generates both. But this may be totally overkill for a single widget. However, for a more complete toolkit…

    • Tom Schindl says:

      Maybe the project development history helps you to understand how things work:

      We developed the things in the following order

      1. Defined the XGrid interface to meet all requirements defined by ITBH
      2. Defined an ecore model with all configuration options provided by the API
      3. Implemented the concrete SWT implementation of the XGrid API
      4. in parallel implemented the EmfGridTableConfigurator
      5. defined the XGridComponent interfaces & implemented the e4 integration

      So beside the EMF-Generated Model classes all you see is written by hand. An idea we have is to provide an DSL instead of using EMF-XMI for configuration purpose but as of today the XMI stuff is enough 😉 We have in depth docs for the Java API and the EMF model at https://github.com/BestSolution-at/framework-grid/wiki/In-depth-description

      • Hallvard Trætteberg says:

        Thanks for the explanation. I understand XGrid is a lot more complex than most widgets, but do you think this is a useful architecture for other widget, like viewers for structured content. Do you plan on something similar for the JFace Viewers, that you blogged about earlier? I would guess that some configuration options could be pretty similar.
        Do you see any role of a model for the widget hierarchy itself, not “just” the configuration of individual widgets? E.g. if a pane (e4 part) needs some more items besides the XGrid, wouldn’t that be difficult with the XGridComponent?

      • Tom Schindl says:

        Many of the concepts in the XGrid API have been taken from the viewer API I’ve been think about since a looong time 😉 To me the XGrid arch and development are the best choice for a possible viewer API 2.0. So there’s a good chance that one day XGrid-API will extend XViewer (assuming this is the name of the new API 🙂

        On the XGridComponent you are right when directly referencing the component one can not embed other controls but you can still use it with something like this:

        public class MyClass {
           @PostConstruct
           public void init(Composite parent, IEclipseContext context) {
              parent.setLayout(new GridLayout(2,false));
        
              Label l = new Label(parent,SWT.NONE);
              
              Composite xComponentContainer = new Composite(parent,SWT.NONE);
              xComponentContainer.setLayoutData(new GridData(GridData.FILL_BOTH));
        
              IEclipseContext c = context.createChild();
              c.setComposite(Composite.class, xComponentContainer);
              ContextInjectionFactory.make(XGridTableComponent.class);
           }
        }
        

        Naturally you loose the toolkit agnostic feature because you write SWT code but there’s not change required to the grid – the magic of DI 😉

      • Hallvard Trætteberg says:

        I did respond to an earlier blog post about the Viewer API and I’m still interested in its development. And more so if EMF is involved, since models of UI is among my fields of interest.

  2. Pingback: XGrid | InformationsTechnologie Beratung Hermann

  3. Pingback: XGrid | InformationsTechnologie Beratung Hermann

  4. Pingback: XGrid | InformationsTechnologie Beratung Hermann

  5. Sascha Hanke says:

    Is it possible to register a Mouselistener/DoubleclickListener on the grid? I got the SelectionListener but I need to know if it was a double or single click.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.