Author Archive

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.

Share this:

Like this:

Version 5 brings hundreds of improvements over Version 4 (limegreen) and has extensively tested and heavily used in real world applications and can be considered the most mature and stable version of betterFORM ever. The detail changes are too numerous to be listed in detail. The curious might however browse the list of changes on Github.

Here a list of the more prominent changes:

XForms sessions can now be be configured to persist to disk after a
preconfigured limit is reached. This dramatically improves scalability
even with limited memory resources as long as disk space is available.
XForms sessions may now remain active for ever!

Libraries betterFORM depends upon have been upgraded to latest versions. Most noteably now Saxon 9.4 is used.

Share this:

Like this:

New eXistdb distribution addresses the needs of professional users

Rüsselsheim, Germany – January 27, 2014

eXist Solutions today announced eXist LTS, a long-term support version of the well-know NoSQL database eXistdb. ‘LTS’ is available as an especially tested and maintained subscription of the community edition establishing a stable application platform for professional and enterprise users. Additional service-level agreements complement the new commercial offerings.

LTS addresses the needs of users that require a stable version or do not have the capacity to follow the open source community in search for improvements and bugfixes. The community edition however will continue to stay free and un-restricted.

eXistdb is used in many application domains and has users around the globe. Started as a native XML database it has grown to a full-fledged application server including an application packaging facility, a browser-based IDE to develop your code as well as various tools to administer and manage the platform. With a fine-grained authorization model and a powerful forms framework it is ideally suited for managing complex data.

eXistdb increases the productivity by using a single data-model across all layers of an application thereby completely avoiding the need for mapping tools. All prominent XML standards like XQuery, XPath, XSL, XML Schema, XForms and others are available for use out-of-the-box. With it’s support for XML and binary data eXistdb is ideally suited for managing semi-structured data. Applications range from content management, eHealth, science, network and configuration management to solutions in the digital humanities, technical documentation, publishing and data integration.

about eXist Solutions

eXist Solutions was formed by the developers behind the Open Source native XML database ‘eXistdb’ to offer commercial support and consulting around the product and XML technologies in general. eXist solutions and the betterFORM team have joined forces to provide optimal support for the product and continue to enhance the platform.

Share this:

Like this:

The answer is simple: eXist Solutions (the company behind eXist-db) and betterFORM have joined forces to integrate their two long-standing projects and offer commercial support for this new platform. As true Open Sourcers we’ll continue to offer this new product as free, Open Source software. Not much change here. But additionally there now will be subscription-based support for those that need long-term reliability for their commercial applications.

Beyond having integrated our products to work seamlessly with each other we have also joined our skill set and experience in the XML domain. We offer this joint expertise to our customers as consulting, development and training services to enable them to build better applications in less time.

Share this:

Like this:

Model Item Properties (MIPs) are one of the central features of XForms. In short they allow to add constraints to XML nodes. The available MIPs are:

readonly – boolean XPath expression

required – boolean XPath expression

calculate – XPath expression

relevant – boolean XPath expression

constraint – boolean XPath expression

type – XML Schema simple datatype or extension thereof

However with XForms 1.1 each of these MIPs were allowed to be attached to a node only once. If a bind element happened to attach one MIP to same node a second time the processor would throw a XFormsBindingException.

This was rather limiting expecially with respect to the ‘constraint’ MIP as in practice it often happens that you’d like to test for more than one condition. Of course you can combine conditions with a simple ‘and’ like so:

<xf:bind nodeset="a" constraint=". &gt; 5 and . &lt; 10" />

But this leads to long and hard to read expressions. Wouldn’t it be much nicer to be able to write:

MIPs in XForms 2.0…

This is exactly what is addressed in the upcoming XForms 2.0. It now allows that one and the same MIP is attached to the same node several time and defines some combination rules. This table was taken from the current XForms 2.0 Draft.

property

combination

type*

all

constraint

all

relevant

all

required

one

readonly

one

calculate

not allowed

p3ptype

not allowed

*To be honest we still couldn’t make much sense out of the fact that the ‘type’ MIP is also allowed to be combined as the use cases seem to be rather exotic. But probably it just lacks a good example. For the time being we haven’t considered that in our implementation.

‘all’ means that all conditions are chained with a boolean ‘and’ so all conditions must become true for the constraint validation to become true. ‘one’ on the other hand combines the statement with boolean ‘or’.

…and beyond

The combination rules for ‘constraint’, ‘relevant’, ‘required’ and ‘readonly’ are now implemented in betterFORM. But we went some steps further and also picked up some of the ideas from a post published under the name ‘MIP Names, Type, Etc.’ on the W3C XForms group wiki.

Besides using the syntax shown above you are now able to write the following statements:

Here we find our good old friend the ‘alert’ element which XForms authors know as one of the child elements of XForms controls to signal an error. The alerts are now attached to a single constraint MIP and allow to tell the user exactly which of multiple constraints has failed in a given situation.

But there’s even more. In some situations even a single condition might be complicated and therefore hard to read. This is especially true when it’s crammed into an attribute. Now you can also write:

One Question left

Great, now we have the ability to signal to the user what exactly went wrong, combine several occurrences of a MIP and we can trigger each UI control bound to that node. But what if we do not want that? It might be even confusing if alert messages pop up in the UI at several places.

So we need a mechanism to selectively and explicitly say that we want an error to be displayed for a given control. We currently solved this like so:

‘srcBind’ is an idref and points to an existing bind with id=’aBind’. This is taken as the root element for all alerts that might be displayed (if their respective constraint fails) or not displayed (if their respective constraint passes). The xf:alert in the UI becomes a container for all messages whose constraint fails and are displayed as a stack.

We hope these extensions are useful and welcome your feedback.

Share this:

Like this:

A while back the XForms Working Group proposed to use @ref Attribute everywhere in XForms and replace all usages of @nodeset. We have followed this proposal and implemented this in betterFORM 5 development branch. This means that you don’t have to think any more which attribute (@ref or @nodeset) is right for the given element.

As a consequence the following elements now also accept @ref:

bind

header

itemset

insert

delete

repeat + repeat-ref

We appreciate this simplification and hope it helps avoiding authoring errors. Of course old forms that use @nodeset will continue to work.

Share this:

Like this:

There was a long standing issue with embeddng of subforms when triggered by xforms model actions like xforms-model-construct-done and xforms-ready. This has been fixed now in the development branch of betterFORM on Github and will be effective with next release of betterFORM 5.0 (SpringBud).