Web Client Plans

 

Thinking and Planning about Web Client(s)

One of the questions we get all the time is "what are you doing about the web?" Sometimes it's a question with a more direct agenda, like, "why don't you have a Java middle tier?"

Or, even more directly, "why are you guys stuck in the 1990's with a GUI client/server system?"

Well.

To begin, we have always tried to keep a light, thin, small-footprint client. Qt, the open source C++ toolkit with which we build the GUI clients (for Windows, Mac, and Linux), has no runtime engine/VM, no runtime license, and the executables are comparatively small. Many customers run a single binary off a network share drive. The GUI client is clean, fast, and a familiar metaphor for average desktop users.

We've also made a major effort to put as much business logic as possible in the PostgreSQL database - hundreds and hundreds of functions in pg/pgsql, triggers, and APIs built as database views to facilitate interfacing with external systems. This makes building new client interfaces to the ERP backend relatively simple. Many of our partners and customers have built various Web front-ends for dashboard-type reporting, business-to-business order management, etc. There's even a terminal-based application on a handheld wireless barcode scanner that loads inventory and shop transactions from the database, and scans the barcodes in real time.

The server does all the work, as designed. But there’s a lot more to be done on this front. If you’ve read about any of the architectural enhancements to version 3.0 and beyond, you know that we’re beginning what we hope will be a migration of all the client screens themselves to the database as well. They’ll be stored as XML UI files, and parsed and presented by our Screen Builder in the GUI client.

Version 3.0 also introduced support for QtScript, or - for all intents and purposes - Javascript.

See where we’re going with this? Our long-term plan is to reduce the C++ client to little more than a container to load the “pages.” At the same time, we are constantly reviewing the various Web toolkits and XSLT presentation methodologies to identify a path forward for a full Web client that does all of the following:

  • Builds the exact same screens, with approximately the same look and feel, as the GUI client
  • Works equally well across Windows, Mac, and Linux – in as many popular browsers as possible, but certainly including at least Internet Explorer and Firefox.
  • Is compliant with all relevant standards bodies
  • Does not sacrifice the fast performance of the current GUI client and direct database connection (this may be the hardest part, even with today’s zippiest AJAX toolkits)

Please add a Comment to this page to share your thoughts, or any links to technologies and tools you’d like us to explore as we continue to move forward down this path.

Thanks!