The purpose of this RFE is to gather ideas and track progress of an Orbeon Labs investigation project. The purpose of the project is to make the Orbeon Forms forms engine available on clients, including online and offline web browsers and mobile applications.
As of October 2016, there has been some progress on this project, including:
We expect to continue progress on this project incrementally.
With Orbeon Forms 3.7 (back in 2009!), we had an implementation which wasn't bad in concept, but was too limited and based on Google Gears (the precursor to HTML5 local storage among other things). Due to those limitations, Google abandoning Gears and lack of interest from customers at that time, we decided not to maintain it anymore starting Orbeon Forms 3.8. See:
The idea is to bring our forms engine to Web apps and "native" mobile apps. This would serve multiple purposes:
The general idea is to make the code which currently runs on the server run on the client, whether within a Web browser directly or as a native application on a mobile device.
We need to abstract and modularize the XForms engine to make it as small as possible and as independent as possible from other things including the servlet API.
The user-interface part would remain browser technology-based. We don't want to change this at all at first and we wants to leverage either an actual Web browser or a Web view within a native app.
We also considered these options, but have opted not to use them:
Abandoned projects, for reference:
Android already supports Java bytecode. This means we have two options:
The Orbeon code needs to be modularized and abstracted. In particular:
Once a prototype is developed, we needs to think about the general architecture of the mobile application, including lifecycle, how to load forms and so on. Form Runner needs to be included, and local storage at least needs to be used.
As of 2015-01-13, the plan to use Scala.js. This way a single compilation can be used:
This also allows us to master Scala.js, which we want to use more for Form Builder (and later Form Runner).
We are trying to define reasonable chunks of work which lead us somewhere. First goals:
It is ok to hack to get to these goals. The purpose is to get familiar with the tool chain, potential issues, and learn more about what remaining work will be needed.
+1 from customer
+1 from evaluator
Immediate concrete next steps:
+1 from evaluator, with a preference for a web app using browser storage, as native apps can be more challenging to deploy.