Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Embedded XForms Server for mobile and offline clients #1221
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.
Subprojects, dependencies, and related projecgts
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.
Native iOS app
We also considered these options, but have opted not to use them:
Abandoned projects, for reference:
Native Android application
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.
Steps for a prototype
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.
Things the client must not need
We will need the handlers offline to support instantiating new forms offline. Right now, this works as follows:
So we need a way to do this when offline as well. We probably need to have
Splitting this into modules/projects is not that trivial. We not only have the runtime/compile-time axis, but the "thin client" (what we have now)/full client axis, and the JVM/JS/shared axis.
For example we don't want the "thin client" to pull down the full client. Scala.js prunes the call tree but it's not perfect at doing that, probably, so it's better if we have a clean separation of the "full client" module, which would contain mainly the XForms runtime.
Client-server communication abstraction:
So for the client-server, we now have:
So probably that we don't need to modify much
Another approach is to make
The second approach might be easier as it's not pulling in
My 2 cents on this:
Why not normal
Depending whether this must support IE, of course. But, even we (working with german hospitals) are phasing out IE support...
@siebertm Thanks for the feedback.
For regular online/offline mode in a browser then yes, Fetch support is needed.
Agreed, and IE support is not a requirement at this point.
For the record, we have now made
Which parts of the static analysis must not be present in the
So we should probably separate the "builders":
So now we are refactoring out all the building of the tree. This will take care of
However we need to solve the question of how to pass in the XPath analysis information. We do this after we have built the tree:
For deserialization, the information should be passed to the constructor. So maybe the constructor of the classes should have the XPath analysis information as
Next step is to move towards serialization/deserialization. This includes:
We can use