Moving forward – betterFORM 6 aka ‘Fore’ is born

After just releasing betterFORM 5 it’s time to move on and plan for the next step. The main focus of Fore will be to sort out the good, bad and ugly from the W3C XForms standard and move the good parts to a more modern architecture.

First a very short analysis of what we’ve found in years of implementing and developing with XForms. XForms is designed as a MVC architecture which is considered a good thing (SoC and so on) nowadays. But if being honest MVC architectures also come to a price. The different parts are kept in separate places which avoids clutter but also calls for more maintainance when things have to changed. Being MVC does not automatically means pure elegance and easy reuse.

Let’s consider the parts of XForms:

• The XForms model
• The XForms UI
• Actions

It’s probably sad but true that 2 of the 3 haven’t really worked very well in XForms. Beginning with the last…

Actions

XForms was designed to be declarative. There’s nothing wrong with that however Actions are procedural in nature and pressing them into a declarative syntax doesn’t help much. In contrast some blocks of Actions can easily become hard to understand and maintain. In addition some of the actions were not designed sensibly. E.g. the insert action with its many combinations of attributes was too powerful to remember its syntax even for a day. Even after years we repeatedly found ourselves looking up in the docs how a certain operation can be achieved. Nobody really wants to write code in XML.

XForms UI

Back in time when XForms was started we slowly saw the rise of many, many different devices. To deal with that the Working Group decided to take the abstract approach and design the XForms UI independent from any concrete device out there. Surely this meant that to become useful XForms documents always had to be transformed into their target UI language. This was doable but except for the overhead also caused some additional trouble.

The mismatch between XForms UI controls (e.g. having their labels as child element) and e.g. HTML forced some tricks on implementers to support all the features. For authors it is simply inconvenient if you get something different rendered out than you’ve auhored. This forced some ‘thinking around the corner’ all the time which often is not helpful in projects under time pressure (which are not?).

Further the transformation process forced to invent CSS classes to handle the specific states the UI can represent. So beyond handling all the associated technologies like XML, XPath, XSD, DOM Events etc. you also need to learn about the specific CSS rules of a specific implementation. The implementors often came up with the similar ideas but each did its own dish. – Another reason why interoperability was never a real option in the XForms world.

It might be due to our personal experience but in more than a dozen years in XForms land we never had a single project where the target language was NOT HTML. HTML had taken over the world not only on the desktop but also on mobiles, tablet, TVs and even refrigerators.

Esp. HTML5 has made significant steps in supporting web- and browser-based applications. Huge innovation has taken place in the JavaScript world with regard to tooling but also in respect to engineering. JavaScript is not a toy language any more and improvements in methodology and conventions allow to build impressing applications today.

With respect to XForms for us this means to drop the XForms UI altogether. It has made our lives harder than necessary for a long time and we’d like to go back to the basics. Face it: what do you write if you start something new and need some data from the user? The overwhelming majority of people will write a plain HTML form to first make it work. Nobody really likes to sit back and think about a clean model, UI, controller separation in the first place. But once you’re ready to go with the details you would need to reimplement the whole stuff in XForms again.

XForms model

The XForms model is the very heart of XForms and pure gold IMO. It allows to setup complex dependencies between data items that are unparalleled even in most advanced client-side JavaScript frameworks. It gives you strong datatyping and the option to work with several data instances and even models in a single context. The XForms model is here to stay in betterFORM 6 but be connected to whatever you prefer for building your UI. There are many very good CSS and JS frameworks out there and there is no reason to lock people into a specific framework or library as long as the basics of HTML5 are respected.

Love to hear what you have to say. Please comment. We’re seeking developer feedback to really make Fore as simple, easy and fun to use as possible.

New home of Fore: https://github.com/betterFORM/Fore/tree/development. There not too much there already but refactoring has already started and a first feature release is not far away.

Not to forget: betterFORM 5 will of course stay to support those who want or need to deal with full XForms 1.1