Stephen Smith's Blog

Musings on Machine Learning…

Posts Tagged ‘gwt

Unit Testing Web UIs in Sage 300 ERP

leave a comment »


Unit Testing is a technique to test individual units of source code. Usually in the Java world this means a set of tests to test an individual class. The idea is to test the class (or unit) in complete isolation from the rest of the system, so calls to other parts of the system would be stubbed or mocked out. Unit test are typically written by the software developer to perform white box testing for their class. Unit testing is only one sort of testing there would be other types of testing for various integration testing, user testing, load testing, manual testing, etc.

The goal of unit testing is to show that the individual parts of a program are correct and then to deliver the following benefits:

  • Establish a well-defined written contract of what the code must do.
  • Find problems early in the development cycle.
  • Facilitate change and refactoring since you can rely on the unit tests to prove things still work.
  • Simplify integration since you know the building blocks work correctly.
  • Provide documentation, the unit tests show examples of actually using the class being tested.

In Extreme Programming and Test Driven Development, the unit tests are written first and then passing the unit tests acts as an acceptance criterion that the code is complete.


JUnit is a unit testing framework for Java programs. It is integrated into most IDEs like Eclipse and it is easy to run the tests from build tools like Ant. Usually in Eclipse you have a test tree with all the test classes, usually a test class for each real class and the test class containing all the tests for the real class. JUnit support a number of annotations that you put on the methods in the test class to specify which ones are tests to run as well as optionally specifying any order or dependency requirements (the best unit tests run completely independently of each other). Then it adds a number of methods to call to test for pass and failure of the tests (via various forms of assert) and to report the results back to the test framework.


The Google Web Toolkit (GWT) supports unit testing with something called GWTTestCase which bridges GWT to JUnit. If you want to interact with GWT controls then you have to use this. However it’s relatively slow. You want unit tests to run blazingly fast. A unit test should only take a few milliseconds to execute. If it takes longer then it won’t be run often. You want it so your unit tests can be run every time you compile and so they don’t slow you down as you work.

We use GWTTestCase to test our extension of the GWT CellTable widget. These tests take 10 minutes to run. This is way too slow to expect them to be run on a regular basis. Hence they don’t provide the immediate feedback to a developer working on this widget that we would like.

Fortunately since in GWT you are writing all your classes in Java, if you structure your program correctly you can have most of your classes not interact with GWT or easily mock the GWT part of it. Then you can use JUnit directly to unit test your program.


One of the key goals of us enforcing MVC design patterns on our developers creating UIs is to facilitate good unit testing. This way if most of the code that needs testing is the Model and Controller, these can be tested with JUnit and we don’t need to use GWTTestCase. This greatly simplifies unit testing and greatly improves the productivity and speed of the tests. Usually our View part is very small and mostly implemented in the SWT framework, so the unit testing is then in framework unit tests (many of which are GWTTestCase), and not in the actual UIs.


EasyMock is a library that can dynamically “mock” classes that aren’t part of the test. With unit tests we only want to test the one class at a time and we want the tests to run quickly. We don’t want to require a particular database be in place and then have to wait for the tests to run as it makes database queries. We want the tests to run in milliseconds and we want the tests to run in spite of what might be happening in the rest of the system. To this end the test framework needs to replace the real classes that the class being tested calls and interacts with, with something appropriate for testing. These test replacement classes then have the ability to return unexpected or rare results such as network disconnection errors, or other rare hard to setup type of scenarios. One way to do this is to write “stub” classes that replace the real classes and then only have code to do what is required for the testing. Writing and maintaining stub classes is difficult since you need to keep them in sync with the classes they are stubbing; keeping these correct can become a major amount of work.

EasyMock offers an easier way. It generates the classes on the fly using Java’s proxy mechanism. This way the class interface is always up to date since it is generated from the real class. You first run in a “recording” mode where you record what you want the various methods to return to the test cases. Then you switch to “play” mode and run the tests.

For this to work effectively, you must design classes so classes they use can be mocked. This usually means creating them externally and then passing them to the constructor rather than creating secret internal instances. Generally this is good object oriented design anyway and usually difficulty in constructing unit tests is a “code smell” that something is wrong with the design.  For simple utility classes or simple classes in the same package, it’s often easier to leave them in place rather than mock them, then they get a bit of testing as well and as long as they run quickly, shouldn’t be a problem.


Below is one of the tests from the BOM Detail popup form in Order Entry. This shows the structure of a JUnit test and shows how to mock a big class (namely the Model) that this class interacts with. Notice that the Model is created externally to this class and passed into the constructor, so it is easy to mock. First we record what the mock class should do and then we switch to replay mode to do the actual test.

public class NestedViewBOMDetailsCallbackTest
private static final int TEST_PARENT_COMPONENT_NUMBER = 42;

* Tests that the callback’s onPopupClosed handler will filter on the child
* BOMs of the parent component number that was passed in at callback
    * creation time.
public void testOnPopupClosedFiltersOnChildrenOfCallerParentBOMNumber()
// Set up the mock model and the expected method calls that should be
// made on it by the class under test.
OEDocumentBOMDetailsModel mockModel = EasyMock.createMock(OEDocumentBOMDetailsModel.class);
mockModel.filterOnChildBOMsOf(EasyMock.eq(TEST_PARENT_COMPONENT_NUMBER), EasyMock.isA(EntryFilterCallback.class));

// Tell EasyMock we’ve finished our setup so that any time we interact
// with the mock, EasyMock records what calls were made on the mock.

// Call the class under test to exercise the method under test.
NestedViewBOMDetailsCallback callback = new NestedViewBOMDetailsCallback(mockModel, EasyMock
            .createMock(BOMDetailsView.class), TEST_PARENT_COMPONENT_NUMBER);

// Check that the expected method calls on the mock happened when we
// exercised the method under test.


Unit testing is an effective form of testing that does find quite a few bugs and helps keep code running smoothly as a system is developed and refactored going forwards. Sometimes the discipline of unit testing forces programmers to ensure they fully understand a problem before coding resulting in a better solution. Certainly this can’t be the only form of testing, but it is an important building block to a quality software system.

Competing Web Development Systems

with 5 comments


The pace of development of Web based applications has been frenetic. The pace of development of tools to program the Web is also frenetic. There are new programming languages, libraries, servers and systems announced daily. Whatever happened to the good old days where you got a new version of Visual Studio and an updated C compiler every three years or so? In this blog posting, I want to look at the problems that people are trying to solve and the innovations they are trying to introduce to address them.

One nice thing about working at Sage is that we have so many products; someone will be using one of the systems mentioned in this article. For instance SageOne and Sage Billing Boss are written in Ruby on Rails. Sage 300 ERP and SageCRM use GWT extensively. Other products use JQuery and Node.JS. Several of the mobile offerings were produced with JQuery Mobile. So within Sage we have some opportunity to compare these on real non-trivial projects.

The Perfect Programming System

The real goal of all this is delivering real value to customers (end users). All other goals are in support of this. Nearly everyone is adopting some sort of Agile development process centered around delivering value (or even delights) to their customers. Once you are delivering customer value, then the next question is always: how to do that faster? Everyone are looking for a software development toolset that delivers customer delights and improves productivity.

That’s the high level goal, but what are the more detailed goals:

  • Quick to enter changes, ideally just edit some code, save it and refresh the browser to see the results.
  • Easy to test. Meaning there are good ways to write unit tests that can run quickly every build. That the system promotes test driven development.
  • Easy to maintain. The system produces readable code that is easy for another programmer to figure out and change.
  • Little impedance between problem domain and language. When thinking about what you want to do, it isn’t a huge change of perspective to write the code; somehow the code reflects what you want to do naturally.
  • Easy to learn. You don’t need to know 3 programming languages, 5 scripting languages and 27 runtime libraries all of which interact in a complicated way to get up and running.
  • Large ecosystem – lots of tools and libraries to save you work.
  • Produces correct code. You don’t have to worry about unexpected syntax errors or other strange unexpected runtime errors that testing might have missed. By the same token you don’t have to spend a lot of time testing for and removing these sorts of things.
  • Easy to install and setup. It’s easy for programmers to setup the development environment and get up and running quickly.
  • Easy to deploy. It’s easy to transfer changes from the development environment to a live environment.
  • Ability to integrate with (consume) modules that are part of legacy systems.
  • The generated code is very small, fast and scalable.
  • Great development tools for debugging, code analysis, etc.

In life, there are many tradeoffs to make. The same in programming. You might want three things, but you can only have two. Which do you pick? Which do other people pick? Usually with a large set of goals, some practical tradeoffs need to be made. Usually there will be a lot of disagreement in a group of people as to which goals are the most important and which ones can be lived without. Often the group will break up into different camps each with the conviction they have made the correct choice and theirs is the correct way to do things. So too with programming and hence all the different camps of web developers. Here we’ll look at a number of the camps and the tradeoffs they are making. Obviously I have my own opinions and preferences and the members of these various camps will probably disagree with my assessments.

For instance would you want to sacrifice several of the items for scalability? Everyone would like to be as popular as Facebook, but if you are a new web site, then perhaps it’s better to go live quicker to get feedback rather than spend the extra time engineering scalability. Often it’s more important to get feedback quicker so you can adapt your plans rather than over-engineer and be slower to market and slower to react. This fits in with the “fail fast” methodology of innovation where you are trying lots of things to see what works, you want them live as fast as possible to see what is good. Then you can take the good ideas and engineer them for the projected growth once you know what that will be.

Client Side Programming

As a Web developer you are targeting being able to run inside of Browsers. Here you can rely on HTML, CSS and JavaScript. Nothing else is common and nothing else will run on a large enough selection of Browsers and devices. If you don’t care about rich interaction or looks, you can just write using HTML and server side code, but this is Web 1.0 and probably won’t be very popular with your customers. There are good layout tools, or just text editors for writing HTML whether it’s static or generated by a server program. For CSS the tools aren’t as good, but there is help from libraries like CSSPie or Sass. Then for JavaScript, you can either write directly in JavaScript or use something that compiles another language into JavaScript; the merits of either approach are fiercely debated. Of course when writing in JavaScript you can use libraries like JQuery to hide the complexities and provide a lot of missing support.

Server Side Programming

You control the server and you control what runs on it, so you can theoretically use any programming language that can receive HTTP requests via a network socket. But usually you want something that integrates with a Web Server like IIS or Apache. There are good server frameworks to create the server programs in Java, .Net, C or any of a thousand scripting languages. Nearly every programming language has been adapted to write Web server applications with, even COBOL.

Client and Server Together

Although it is possible to program the Browser and the Web Server completely separately and independently. Perhaps only communicating through a well defined RESTful Web Services protocol. Usually we would like to leverage the skills of one to help with the other. We would also like a unified debugging and problem solving system. We would also like to reduce the number of specialized tools that people need to learn. Wouldn’t it be nice if the separation between client and server is largely transparent to the programmer? How well the client and server environments are harmonized is often a critical deciding factor in decision making.

Some Leading Development Platforms/Libraries

JQuery is a leading framework for developing using raw JavaScript. The innovation with JQuery was separating the JavaScript code out from the HTML that it controls. It uses a method to interact with the HTML very similar to CSS. The Query part of JQuery refers to how you build queries to specify which DOM objects to operate on, rather than having the JavaScript attached to each DOM object directly. JQuery has a powerful extension framework allowing many powerful libraries to be added to JQuery like SproutCore. A key goal of JQuery is to separate the JavaScript code from the HTML and then to insulate the JavaScript programmer from many of the Browser dependent parts of JavaScript like making AJAX RPC calls. The difficult part of JQuery is how it interacts with the DOM, although very powerful is quite complex and tricky. JQuery by itself is a client framework, but it integrates to pretty much any server framework. In fact Microsoft has given up on running .Net in the Browser and is now promoting using JavaScript with JQuery communicating back to .Net running on the server.

Node.js is a JavaScript server framework. For people who love JavaScript and JQuery, it then kills them to have to program the server in something else like Java, .Net, PHP or Ruby. They love JavaScript and would like to do all their work in JavaScript. With the Chrome Browser, Google introduced the incredibly powerful V8 JavaScript engine. Node.JS then uses the Chrome V8 engine to run JavaScript on the server. Additionally the Node.js developers consider using a thread to execute each web request as too much overhead (nearly every other server framework uses threads). So they also brought all the asynchronous ideas associated with JavaScript from the Browser to the Server. So anything that is executed outside of Node.js is done purely asynchronously, such as calls to the database, operating system or such. This is very powerful and very low overhead for highly scalable systems. However it is fairly difficult to program with (according to me, not Node.js fans). To help tame the asynchronous problem, Bruno Jouhier, an Architect at Sage developed streamline.js which he talked about here.

Ruby on Rails is a server framework for developing the server side of things in the Ruby scripting language. In a way Ruby on Rails is a contradiction, since it is a framework that was developed to eliminate frameworks. Many people feel that frameworks and libraries just get in the way. Why do you need all these middleware components to connect things up? Why can’t the UI just access things in the database directly without a lot of messing around with intervening layers? Ruby on Rails implements web screens using a strict MVC model, where Ruby helps generate the Model part directly on SQL database tables, so the Model part is your business logic. After all why would you need anything else? Ruby on Rails is a server framework similar to ASP or JSP, but people want AJAX web applications, so you write any richer or interactive parts of your web pages in JavaScript with JQuery that then talks back to the Ruby components on the server.

Google Web Toolkit (GWT) is a framework where you program in Java which is then compiled to JavaScript for the Browser half of the application. The server side is programmed in Java which runs as a Java Servlet under a Java container like Tomcat or Jetty. The nice thing is that you do all your programming in Java so you are only using one language. You also get to use all the thousands of tools and libraries that have been created for Java over the years. Since it’s a compiled language, you will not get runtime errors due to typo’s in your code like you do for scripting languages (some just ignore the errors which is even more confusing). On the downside you have to compile your code, so you can’t run it as quickly as you can with a scripting language. I’m not really sure which is faster, since when I use scripting languages I’m always fixing undefined variables and syntax errors, so although I can run quickly, I have to run many times to get things working. GWT also lets you use the Java symbolic debugger to debug your code which is very helpful.

Dart is a new project from Google that attempts to combine the best of the worlds of JavaScript/JQuery/Node.JS with Java/GWT. The idea is that Dart is a structured object oriented language (like Java) but you can choose whether variables need to be defined and adds a number of dynamic features usually only seen in scripting languages. Then the idea is that Dart can be run in some Browsers natively, allowing scripting type rapid development and for Browsers that don’t support it (like probably IE), you compile Dart to JavaScript. Dart isn’t ready for primetime yet, and it isn’t clear whether it will succeed, but it does show that the pace of development of these tools and systems is continuing at a rapid pace. Some theorize that the real intent of Dart is to replace Java as the tool used to develop Android applications, mainly due to all the frivolous lawsuits from Oracle.

Which to Choose?

The choice comes down to which items are most important to you in the list of what makes a perfect programming system. Which one gives you the best vibes, or feels right for what you want to do. Often this is heavily influenced by your current experience; what technologies are you most fluent in already; which new ones will you need to learn. This usually goes beyond a single person and you have to consider the expertise and experience of your development team.

A big influencer is whether you are writing a new system completely from scratch or you have to extend or integrate to a large existing system. If you need to extend or integrate then often your choices are limited to things that can easily do that. If you are writing a new system then you are much free’er to choose. For the new system, often it depends how much you want to rapidly prototype, versus how much the requirements are set and you want to implement quickly.

You also have to consider the longevity of the tools you are choosing. Perhaps you don’t care since you just want to rapidly prototype and start from scratch every few months. Or perhaps you know the system you are developing will need to be maintained and extended for the next ten or twenty years. Then you have to look carefully at the health of the open source community around the tool, or the commitment of the company behind the product to keep developing it.


There are many more systems in use. As I mentioned, nearly every programming language ever invented has a Web Development framework. People fuss quite a bit about which one to use, but I think once you bite the bullet and dive in, you can’t go that wrong with any of these. Also most of these can interact and interoperate at different levels, so usually you can build a composite system using many different tools (you just have to learn them all). Anyway the Web continues to be a platform that promotes innovation and fosters continuing learning.

Sage 300 ERP Web UIs and CSS

with 2 comments


Last week I blogged about using MVC to program the new Sage 300 Web UIs, this week is an update on how we lay out the forms for the new UIs. I blogged on the previously here; but, this article is quite outdated now, everything mentioned will still work, it just isn’t the preferred way of doing things. This week’s post is an update on how we are now laying out forms and applying CSS to best effect.

In the early days of the Web there was only HTML. HTML was designed to structure content, mostly for scientific papers. Over the years, HTML was extended to allow more content types and to add tags for formatting. HTML has always had a set of table tags which were intended to display tables of numbers, usually produced by various scientific experiments. Clever web designers then figured out how to layout quite sophisticated layouts by using these table tags, by putting tables inside other tables and such. These ideas were extended for a while until it was finally realized that HTML was getting over-burdened and that we really needed to separate the content from the formatting. This was when Cascading Style Sheets (CSS) were introduced.

The intent with CSS was that people would stop using various formatting tags in HTML (like the font tag) and would instead do all their formatting in the CSS. Then in HTML tags would only be used to specify content like paragraphs, sections, copyrights, etc. Then tables would only be used to represent proper tables again. However for compatibility all the old HTML tags had to be left in place, so now we have a situation where you have to know which tags in HTML to use and which not to use, because you should use CSS. If you want to layout your pages using CSS then you need to use the HTML div and span tags which don’t do anything except give CSS a way to control your layout, then you want to avoid the older layout tags like the table ones.

CSS is used both for layout and for controlling the detailed look of content elements. This blog posting is concerned with the CSS features to do with layout and not the features to control things like color and font style. That would be a large blog posting in its own right.

GWT provides access to both the HTML way of formatting and laying out pages as well as the CSS method of laying out pages. Some GWT layout controls like the grid, horizontal panel and vertical panel wrap HTML table tags. Some GWT layout controls like the flow panel and simple panel wrap HTML div tags. This can be tricky since the GWT documentation isn’t always clear on what DOM elements are being created by a given control. But generally if you aren’t laying out the form via CSS then use all the panels, if you are using CSS then you will only use a couple of GWT’s layout panels.

CSS lets you control layout in a liquid or flowing manner, or control the layout by using fixed absolute placements and sizes (usually in pixels). Generally we want a liquid layout, so that our pages can be resizable and automatically adapt to different screen resolutions and still look good as various parts are hidden or shown depending on application options.

If you read a book on CSS (and there are many excellent examples), you quickly notice that all the terminology is from typography and magazine layout. Sometimes it takes a bit of getting used to this, so you can see past the terminology and apply the ideas to the layout of your form. This just takes a bit of patience and time to get used to.

How Sage 300 Uses CSS for Layout

The main way that you control form layouts with CSS is through controlling things in HTML div tags. These were designed to have CSS attached to them and then you move them by floating them around and controlling their size and dimensions. First let’s consider a simple form with labels, textboxes and sometimes a menu icon to the right of the text box. Since we want to control the placement of each control we wrap it in a Simple Panel and place them in flow panel’s as the diagram below indicates:

We then build up rows of the controls we want. Then to break each row we have a simple panel with the clear style which then acts as a line break. As you can see from the diagram this leads to a fairly simple setup, but it doesn’t look like it will lead to much of a page. But this is how we lay it out in HTML, and then we will leave it to CSS to make this look pretty.

To build up more complicated layouts we nest these. So for instance if we want a two column display then we put two flow panels side by side and then build the above idea in each one. The below diagram shows how this level is setup:

The labels in the diagram are the styles applied to these flow panels. Now you might think that we are just doing what we did with HTML tables at this point, having to nest them in complicated ways to get our effect.  This is true to some degree, but we have more control. For instance in a table control if you want to hide one cell, then the cells below will not move up to fill it, because this is a logical table. Cells only move up if you hide an entire row of cells. In the CSS scheme things will move up whenever there is room (unless you tell them not to), so this keeps forms much cleaner looking when parts are removed.

Another thing that controls layout is the CSS box model. This is the mechanism where you can put margin, padding and border around any element that you apply CSS to.

These elements give you a lot of control around how you position elements on the page. If you make the left padding of a flow panel large then you push the things contained in it right, etc. How to really control the fine details of layout using the box model can be a bit confusing at first, but it is easy to look for examples on the web that show all the tricks.

In the Sage 300 ERP SDK we provide a SwtDefault.css that contains all the styles you need. Then if you create your declarative layouts as we indicate and follow our style guidelines, you should get nice looking adaptable screens fairly easily. So basically it contains a lot of styles that are intended to be applied to simple and flow panels. These are intended to setup various page design patterns that we document in our UI guidelines. They then have the various floats to format the rows and to setup multi-column displays. They also include all the correct settings for the box model so that everything is spaced and sized correctly. This gave our interface designers a very fine grained level of control over the look and placement of all the controls.


Hopefully this gives you a flavor for how we are using CSS to layout our forms. CSS is a large topic, but for an application developer it’s really a matter of having a basic understanding so you can use the palette of styles that are provided by default effectively. If you are really advanced you can change the CSS files to completely change the way Sage 300 screens look.

Written by smist08

November 5, 2011 at 4:18 pm

Sage 300 ERP Web UIs and MVC

with 2 comments


We spent the last couple of blog posts talking about our new Sage 300 ERP (the product formally known as Sage ERP Accpac) server side programming framework and gave some examples. This week we are going to start turning our attention to the client side. We will be looking at how to structure the code in a UI form to create a well-structured Web Form, using SWT. We’ve refactored the client side SWT (Sage Web Toolkit) framework quite a bit since I wrote this blog post, so we’ll cover how that all works in detail over following blog posts.

Model-View-Controller (MVC) is a common design pattern in software architecture for designing UI programs. People tend to adopt the MVC design pattern, since it enforces some order on the creation of a UI program separating out the various parts into separate classes. This make the program more maintainable, but there are some other goals as well including allowing the UI look to be changed easier and to make the UI form easier to test.

In the diagram above, the dashed lines represent actions that happen directly from events, either from a user interaction with a control on the View or via something changing in the model perhaps due to receiving an SData data source event. Everyone draws this diagram a bit differently and no one really ever likes how data binding fits into this framework. But data binding is just too useful to do away with, so often the model is representing excluding any data binding. In some cases the model doesn’t generate events, but for us it does since changes in one part of the screen will generate changes for another through the model. So in a way this is the Sage 300 MVC design pattern.

We’ve adopted the MVC design pattern for all the new Sage 300 ERP Web Based UIs. We use the same design pattern for the main form as well as for popup forms. Within Sage 300 this gets a bit confusing since we use the name “View” for our business logic. However in this discussion a “View” has nothing to do with business logic and instead represents the actual visual part of the form with all its controls and such. The Model represents the Business Logic and is the part that communicates with the real Sage 300 Business Logic (in other discussions called Views).

There are quite a few other design patterns that are variations on this such as MPP, and several others. Sometimes the differences are subtle, but in our case we find it more convenient to stick with call it MVC model and frame things in regard to this. In a way our application programmers really program in a more MPP model, since all the direct communication between the View and Model is really handled by the SWT framework as part of our data binding support.

One of the key goals of these design patterns is to move as much code as possible away from the actual user interaction part. This is because testing user interaction is hard to unit test and requires specialized tools like Selenium to simulate real users pressing buttons and entering text. Anything that doesn’t directly interact with a user can be unit tested using regular tools like JUnit. Tests using JUnit are easier to include as part of the build process and so catch errors much quicker. So this approach allows much more of our code to be unit tested and facilitates test driven development.

Sage 300 View

Our View part of MVC is the declarative layout. This is the XML file that defines the form layout. This file defines all the controls, their layout and their CSS styles. We also provide a WidgetHelper class as part of SWT to simplify interacting with the controls on the form. The WidgetHelper class isolates the Controller code from having to check for controls being null (say because they were removed due to customization) and other details.

By keeping the View isolated from the other code, it makes it easier to replace the declarative layout either due to customization or due to special needs, like providing an iPhone version of a layout that is optimized for touch and small screen size.

Within our framework we have the ability for the View to create and define “Actions”. These actions can then be bound to the controls in the declarative layout. These actions are then the events of the View. This allows a greater level of customizability, since people can change the action that is called in the declarative layout to their own action to customize the behavior. Then the Action is the event that the controller receives rather than an underlying control event. So rather than the controller being notified of a button click, it’s notified of say a “save” action. This then further separates the details of the View from the controller (i.e. it isn’t tied to an exact specific control event).

Sage 300 Model

The Model manages the behavior and data of the application. It answers questions about its state and responds to requests to change its state. The Model encompasses the business logic, its state and the SData data source (including events). The model doesn’t just send data source events to the controller, rather it translates them into something higher level that is meaningful for the controller of this process.

We provide a couple of base Model classes in SWT that you can extend for your own applications needs. These base classes include support for interacting with the SData data sources and setting up the eventing mechanism.

Sage 300 Controller

The Controller responds to user and model events, informing the other to change as appropriate. Basically the Controller orchestrates the whole process and is usually responsible for creating and initializing everything as well as tearing down and releasing everything.

If things are written correctly then you can almost think of the controller as a workflow manager, which is controlling the workflow as things happen in the Model and the View.


When you press the “Ship All” button on the Order Entry screen, you would think it simply issues an SData service request to the server to call the Order Entry header view to process the request. However there is a bit of error checking first and then afterwards things need to be updated accordingly. Still this is about the simplest example there is, and can serve as a simple example of the MVC process.

Below is a UML process diagram showing, in gory detail, the whole “Ship All” process. The heading show the various components involved and whether they are part of the View, Model or Controller.

Keep in mind that many of the steps here are automatically handled either by GWT or SWT, so most of the application programming is in the ship-all controller to orchestrate the process between the View (User Interface Form) and the Model (wrapping the Order Entry SData feeds).


You might think that a screen only really requires one model or one controller. This is the case for many popup screen and many simple UI forms. However for larger screens like the main Order Entry screen this would lead to an extremely big model and controller. So conceptually we break down the main OE controller into many smaller controllers and similarly even though we have the main Order model, there can be many sub-models under this. Basically we don’t want our classes and objects getting too big. We want them all to stay maintainable and testable. We want to be able to work on one without breaking unrelated functionality elsewhere.

We also don’t want to create too big an MVC framework so that it requires a lot of boiler plate code to create these; we want the creation simple and if a part isn’t required in a certain situation, then it can be safely omitted entirely.


Hopefully this gives an idea of how we are using MVC as the model for our new Sage 300 ERP Web UIs. Perhaps this discussion is a bit theoretical at this point, but hopefully this will set the stage for looking at the mechanic of this in detail over some following posts and starting to look at some code.

Written by smist08

October 29, 2011 at 5:23 pm

Accpac, GWT and other Web Technologies

with one comment


Last weekend I travelled down to Seattle, Washington for a nice getaway weekend and to see the Science Fiction exhibits at the EMP.  Then on Monday night I gave a presentation to the Seattle GWT Users Group on Sage ERP Accpac’s use of the Google Web Toolkit (GWT) in our 6.x product line. I found the group to be really knowledgeable and they asked great questions throughout the presentation. I learned a lot from the meeting and from chatting with the various people attending. Definitely very worthwhile. I previously blogged about Sage ERP Accpac’s use of GWT here.

Games on GWT

id Software makes many of the most popular first person shooter games including Doom, Quake and Castle Wolfenstein. Their lead programmer is John Carmack who is a legend in the gaming industry. One of the cool things they do is release the source code for some of their older games. They also port their games to various platforms, so often there will be an OpenGL version as well as a proprietary version, and perhaps a version ported to Java as well as the original version in C. A key metric of new computers, operating systems and devices has been how well they run the open versions of these games. I was really impressed when Google ported Quake II to GWT. Seeing Quake II work really well in the Chrome browser just using HTML5 was really really impressive. To me this really showed the power of the Browser as an application development platform, that if you could get Quake II running with a reasonable frame rate, then getting ERP screens going should be a piece of cake.

Of course the times have changed and Quake isn’t the most popular game anymore. So I was really surprised to see the latest hit game, namely Angry Birds ported to GWT. Angry Birds originated as an iOS game that has been hugely popular on iPhones and iPads. Angry Birds has perhaps more than anything been the killer application that has driven people to these devices. Of course Rovio wants to capitalize on the success of the iOS game, by porting it to other platforms. The easiest way to do this is to port it to HTML5 so it will work on all platforms, rather than doing separate ports for Android, Windows, WebOS, Blackberry, etc. For some more details on the porting of Angry Birds to GWT, have a look at this blog. GWT seems to be becoming quite a good technology for developing HTML5 based games. Many people are predicting that doing separate ports to all the mobile platforms, desktop platforms and game consoles is already way too expensive and most game development houses are looking to solve this with HTML5. This won’t work for all games, but it will work for many of the popular classes of games that are so popular these days.


Cascading Styles Sheets (CSS) are a fundamental part of the Web today. All Web Sites use CSS to some degree to control their appearance and layout. Knowing and using CSS is a fundamental skill required of all Web developers. However CSS can be quite hard and quite tricky. When we use GWT it solves the problem of JavaScript differences between the browsers and does a really good job of this. However GWT only makes sure that you can use CSS, it doesn’t help you write it and it doesn’t shield you from Browser differences. There is a CSS version 3 standard that everyone purports to support. However support for this standard is variable across the different browsers. Generally for what we are doing, things work great in Firefox, Safari and Chrome. But then they break down in IE. Plus the support is quite variable across different versions of IE and since MS doesn’t support all versions on all their operating systems, software vendors get stuck supporting several versions of IE, all with different CSS bugs and omissions.

Fortunately we discovered an open source project called CSS3Pie which fills in many of the gaps missing in various versions of IE’s CSS3 support. What CSS3Pie does is recognize the version of IE and when CSS is processed, if IE can do it correctly then it lets IE handle it. But if IE can’t do it then it performs the operation for IE using JavaScript. I hope the Microsoft programmers on IE’s CSS handling team see this project and feel bad seeing how others implemented what they claimed was too hard.

When we started moving our Accpac screens to the Web we did all the layout using DOM layout nodes (which are abstracted as layout controls in GWT), but over time as we’ve become more proficient in CSS and now that we don’t have to worry so much about IE’s deficiencies, we are actually doing much of our layouts using CSS. This tends to lead to finer control than you can obtain using layout nodes so we can refine our look and feel to a higher level.

Asynchronous Programming

One of the reasons we chose GWT as the foundation for our new Web UIs, was that GWT was all about AJAX fundamentally from the start. AJAX wasn’t tacked on later to a system that was really from the Web 1.0 days. The support for AJAX in GWT is really great; but, our programmers coming from the VB world sometimes have trouble wrapping their heads around it. One of the fundamental differences between programming for the Web versus Client/Server is the issue of latency and how this accumulates as messages move across the Web. As the Web has progressed we now have tremendous bandwidth; so there are services that can stream a 4Gig movie to you in less than half an hour. However if you need to send a message across the Internet and wait for a response, it might takes 100ms which is still really fast, as long as you are only doing 1 message. If you do 10 messages then it takes a second, 100 takes 10 seconds, etc.

Programmers used to client/server programming on a LAN that probably spans only 1 building, don’t have to worry about this. Their latency is less than 1ms and they can make 1000 calls to the server without annoying users with a delay too much. As client/server programmers move to the Web there is a strong discipline required that if you have a process that require 10 server calls, then it must be re-factored to only require 1 call. Within our SWT framework, we make it easy to make 1 call, but don’t provide any help to string together multiple calls. This is intentional. Then we provide a good framework for our programmers to move “bad” code from the VB UIs into server classes where they can make many calls without penalty.

Perhaps the point here is that you need to do this independent of the Web programming framework. GWT has good support for AJAX, but it falls to the application programmers to use it correctly and this mind set change is really a function of moving to the Web rather than the choice of Web technologies.


Sorry if this blog posting is a bit disjointed. This is really just some thoughts based on discussions at the GTUG meeting on the pros and cons of GWT as well as adapting to other general Web programming models.

Written by smist08

September 24, 2011 at 10:21 pm

Moving to GWT 2.1

with 5 comments

One of the good things about moving to Web development is how fast things change. When we developed using Visual Studio for Microsoft Windows, there would be a new version every three or four years and things didn’t change that much. At least until .Net came along, then there was one very big change and then things resumed at their usual pace. With the Web world and using the Google Web Toolkit (GWT), there is a new release every three months or so and many of these releases involve fairly major changes. Fortunately we had adopted the Agile Software Development Methodology at the beginning of Accpac 6.0. This gave us a mechanism to live with-in the fast changing world of the Web.

At some point during Accpac 6.0 development we froze taking new versions of GWT. This was part of stabilizing our product, so we could finish all the features and produce a solid release. The version we froze on was GWT 1.7. Part of this was that the next release was 2.0 and we felt absorbing those changes could jeopardize our release date. Now that we are onto Accpac 6.1 development we have moved up to the current version of GWT which is 2.1 and are excitedly awaiting the release of 2.2. We will try to stay current with the newest version of GWT for as long as possible through the Accpac 6.1 Agile development.

This blog posting will talk about some of the new features that we have picked up moving to GWT 2.1. Some of these provide better product functionality and performance. Some of these provide better developer productivity.

New Event Model

The big change for us going to GWT 2 was a change in the event model. Up until 1.7, you added a listener to receive any event. Basically you just registered the object you wanted called when the event happened. This model has been replaced by a handler model. There are quite a few technical reasons that make this a better approach, but for us we gain two main benefits. One is that it sends all the events through a central queue and makes the order that things happen much more predictable. This greatly simplifies things for us and allows us to simplify our code and not worry about so many cases when focus is lots and such. The second thing is that it vastly improves keyboard handling. The keyboard handling is a major concern for the productivity of heads down ERP document entry clerks. With this change, the keyboard handling becomes much better, especially making it uniform across all browsers.

New Table Control

Another big change is to the Table control. Google has re-written the built-in table control from scratch and called it the CellTable. The table control is now much lighter weight and provides better functionality and performance. ERP packages rely heavily on their table control for fast efficient data entry. Google is a pioneer in getting the most power out of Web Browsers. With the new table control they have raised the bar over all competing libraries. For Accpac it is nice to get this extra functionality at very little cost from the core GWT library. The CellTable is part of Google’s new Data Presentation Widgets which introduce a very efficient virtual scrolling scheme that we are taking advantage of. Virtual scrolling is the ability to load just a small window of the total records available into the Browser, but then load additional records as needed as you scroll around.

Client Bundles

GWT 1.x had the concept of an image bundle. Here you combined a bunch of small image files into a single large image file. This improved performance by only having to download one file (or check if one cached file has been updated) rather than a whole bunch of small files. Generally reducing the number of round trips to the server. Modern Web Sites are generally composed of many small graphics that provide visual richness with aspects like rounded corners or special shading that HTML doesn’t provide by default. We use this in the current product to help the initial Portal page load quicker. GWT 2 then extends this concept, with client bundles, to let you bundle together other common resources such as XML files, CSS files and more image files (a few specific ones couldn’t be bundled). This then improves our performance further by removing these files from needing to be downloaded separately.

Deferred Binding

GWT 2 introduced a feature called Deferred Binding, this allows us to build several Accpac screens together as one GWT object. The advantage of this is that it improves caching. You only run what you need for a screen, but then the Browser can cache all the shared bits, so running one screen, will help speed up the running of the next screen. This also saves some disk space (not that this is so important these days). A bigger advantage of this is that is speeds up our compile or build time, since it takes about the same time to build 10 bundled screens as 1 separate screen, so we can get a 10x improvement in build times. This greatly helps us with our continuous build/integration environment to be quickly checking things as we check in new code.

Eclipse Plug-in

With GWT 2, Google has greatly improved their Eclipse integration. There is now a Google plug-in for Eclipse that adds direct access to a number of tools and wizards. This is nice for developers to have quicker access to a number of things.

In Browser Debugging

With GWT 1, you had to debug using Google’s built in hosted mode debugger. This caused some differences between debugging and running in a real Browser. With GWT 2, you now debug directly in the Browser. Debugging is controlled by a browser plug-in which are available for IE, Firefox, Safari and Chrome. This is nice because now you can check out how style sheet changes work in different Browsers while you debug.

Below is a screen shot of an Accpac screen running in the Chrome Browser stopped at a breakpoint in Eclipse:

At this point we can examine variables, single step through code and do any normal debugging activities. Then we can resume execution:

Better Code Generation

As Google develops GWT, with each version they make the code more efficient, so we get some benefit just by re-compiling with GWT. Plus as Browsers evolve GWT can take advantage of newer features to reduce code size and enhance performance. Especially as various parts of HTML5 start appearing in various Browsers, our programs automatically will use these features where it makes sense. The evolution of the Browser is accelerating again, IE 9 should be released soon, Firefox is planning three releases this year and Chrome is speeding along as usual.


By using the Google Web Toolkit, Sage ERP Accpac is able to gain many advantages from version to version just as a result of using this toolkit. Combine this with the applications features our programmers are adding and we’ll see the speed of Accpac development really accelerate.



Written by smist08

February 12, 2011 at 4:44 pm

Posted in sage 300, Software Architecture

Tagged with ,

Client Logic for an Accpac 6 Web Form

with 6 comments

Last week we talked about creating Accpac 6 Web UIs ( Part of the process is creating the XML representation of the Web Form which we discussed previously: Now suppose you have an XML form designed either in an XML editor or using our SwtUIDesigner and you want functionality beyond that which is given to you by default. By default you have record navigation, save and delete. From last week’s article you will now have a simple runnable project. So where do you put your client side code? Within the client files is a file which contains:

 * Copyright 2010 Sage Software Inc. All rights reserverd.
package com.sage.accpac.SS60A.ss1005.client;
import com.sage.swt.client.ui.builder.AbstractSynchronousFeatureModule;
import com.sage.swt.client.ui.builder.InstanceContext; 
public class SS1005FeatureModule extends AbstractSynchronousFeatureModule
   public String getDebugName()
      return "SS1005 Feature Module";
   protected boolean handleInstanceLoaded(InstanceContext context)
      // TODO: Handle what happens when an instance context is loaded.
      // Return true if the handling was successful; false otherwise.
      return true;

This is where you put your code. The handleInstanceLoaded routine is provided for you to hook your code in. Basically this is called once the UI has initialized and the XML form has been processed and everything has been created. At this point you can hook into any UI controls, data sources or do any other initialization you require. The context that is passed into this routine is the object from which you can get to everything else in the UI. It contains the collection of controls on the form, collection of datasources , etc. Below is a snippet of code for a simple handleInstanceLoaded routine that retrieves a button from the context by calling its getWidgets() method. Then it calls addClickListener() to add a listener that will be called whenever the button is clicked.

   protected boolean handleInstanceLoaded(InstanceContext context)
      DefaultAllClickListener defaultAllListener = new DefaultAllClickListener(context); 
      SwtButton btnDefaultAll = (SwtButton) context.getWidgets().get
          ( UIConstants.WidgetIDs.CONFIG_BTN_DEFAULTALL );
      if (null != btnDefaultAll)
      return true;
   private class DefaultAllClickListener implements ClickListener
      public DefaultAllClickListener(InstanceContext context)
      public void onClick(Widget sender)
               SwtMessageDialog.MessageType.CONFIRM, "",
               new MessageDialogListener[] {new ConfirmDefaultAllListener()});
   private class ConfirmDefaultAllListener implements MessageDialogListener
      public void onRespond(MessageDialogEvent evt)
         SwtMessageDialog.ResponseButtonType response = evt.getResponse();
         if (response == SwtMessageDialog.ResponseButtonType.YES)

Notice that we defined a new class DefaultAllClickListener which implements ClickListener. Basically this is defining the class for the object that will be called whenever a button is pressed. So in handleInstanceLoaded we call “new DefaultAllClickListener(context)” to create a new object in the DefaultAllClickListener class. This object will now be called whenever the button is pressed. In Java this is the typically way you get event notifications. There is nothing like a COM Event special type of method. Event handlers are just regular methods in regular classes. You hook them up by passing them to the object that does the notifying, usually by some sort of addXXXListener() type method call. It’s up to each routine that does notifications to keep a list of all the objects they need to notify and to call each one in turn whenever anything happens.

This is true for all UI events, notice that even the confirmation dialog displayed has a ConfirmDefaultAllListener() that will be called when the button is pressed on this dialog. All notifications are asynchronous like this. You can’t call a UI action and expect to wait (in the code) for a response. If VB we could just do answer = MsgBox () and our code would wait for the user to choose Yes or No. In the browser, everything is asynchronous, nothing waits, everything is via notifications. This is a different metaphor than people are used to. In languages like VB some things are asynchronous and work via event notifications and some things are synchronous. The big difference is that calls to the server are asynchronous, so whenever you make an SData call, you are notified via this mechanism when something arrives. Contrast this to VB where you make a server call, your code waits for the response and no more code is executed until you get it. In the web world this could take quite a long time and the browser would be completely unresponsive if no code executed until you got this response. This is the world of AJAX (Asynchronous JavaScript and XML ). AJAX is the key to creating rich internet applications in the Browser. If we didn’t use this, then the input forms would be quite boring lists of titles and edit boxes followed by a submit button, where nothing happens until you hit submit. This is another reason that you want to put groups of View calls in your server module, where everything works synchronously as normal. Generally you only want to make one server call at a time, since then you don’t need to chain together a number of responses, plus you get the performance benefit of only making one server call over the Internet.

Here we’ve been putting the code in the file, but unlike VB, there are no restrictions on how many source files you have and no rules that certain things have to be in certain files. So you can freely create as many class files as you like and organize your code in whatever manner you like. The nice thing is that you can follow industry best practices and aren’t under constraints like an event listener has to be in a special file in order to be called. So the expectation would be that you can create common Java libraries to share over UI projects and that you can keep your class files small and maintainable without putting everything including the kitchen sink into the file.

One aspect of Java that trips up VB (and C) programmers is the use of inheritance. When using an API or framework in C or VB, basically you look for all the functions, properties and events you can use. If you take this approach with Java, you will probably find that you are having trouble finding what you are looking for. This is because Java supports inheritance in a proper object oriented manner. So often the paradigm isn’t to do something by calling API functions, rather what you do is extend a class that does much of what you want and then just add the code that’s needed to make the difference. People new to Java often take a bit of time getting used to this. If you are stuck and aren’t finding an API that you are sure must be provided, instead look for a class that is along the lines of what you need that you can extend.

This code is Java and definitely not JavaScript. Yet this is what we are writing to run in the Browser. To produce the final runnable code we have to feed this through the GWT Compiler to get it compiled into JavaScript. The GWT Compiler will produce 6 versions of JavaScript from this code, one optimized for each major Browser family including WebKit (Safari and Chrome), Gekko (Firefox) and separate versions for IE 6 and 8. This then is the final code that you would deploy to your customer’s web servers to run.

In the meantime while you are developing, you keep working in Java. You can run this code as a Java application inside the Eclipse IDE. You can use the Eclipse Java debugger to single step through the code, set breakpoints and examine variables. You can also use all sorts of other Java tools to make yourself more productive like JUnit (, Emma ( or TPTP ( Plus you can use all the plug-ins that are available for Eclipse such as say SubVersion for source control (

All the methods are documented in the HTML JavaDoc which is generated from the comments in the source code. This is included as part of the SDK. Below is a sample of the beginning of the page that documents the InstanceContext. This page documents all the methods in this object.



Generally you can do quite a bit of customization just with the screen XML file. But at some point you are going to have to write some code to do the more deep customizations. To customize such UIs with code, you basically want to get hold of the context object, so you can access the collections of widgets and datasources. Then you can add your own listeners, or change the properties of the various objects. Basically you extend the main entry point class of the UI and extend the xxFeatureModule class. Add your functionality and then feed everything back through the GWT compiler to generate a new set of web pages to deploy.


Hopefully this gives a flavor for how the Browser part of a UI control is coded in the new Accpac SWT framework. Most of the basic functionality is automatic from the XML screen definition, but UIs are more complex than just CRUD (Create/Read/Update/Delete) and this is how you add that extra complexity to handle sophisticated UI needs.

Written by smist08

August 21, 2010 at 4:31 pm

Posted in sage 300

Tagged with , , , ,