XForms describes itself as a MVC architecture:
An XForm allows processing of data to occur using three mechanisms:
- a declarative model composed of formulae for data calculations and constraints, data type and other property declarations, and data submission parameters
- a view layer composed of intent-based user interface controls
- an imperative controller for orchestrating data manipulations, interactions between the model and view layers, and data submissions.
Micah Dubinko argues that the mapping is more obvious with Model-view-presenter (MVP), a derivative of the MVC software pattern but that’s not the point I’d like to make and I’ll stick to the MVC terminology where:
- The model is composed of XForms instances and binds
- The view is composed of the XForms controls together with the HTML elements and CSS stylesheets
- The controller is composed of the actions
Orbeon Form Builder goes one step forward and adds a fourth concern for localization and we get a model/view/localization/controller pattern.
This separation of concerns is great to differentiate different roles and split work between specialists but doesn’t play well with modularity and reusability.
I am currently working on a project to develop big and complex forms and this is becoming one of the biggest issues: these forms share a number of common fields and group of fields and, not even speaking of sharing these definitions, this separation of concerns adds a significant burden when copying these definitions from one form to another.
To copy a field from one form to another you need to copy definitions from the model, the view, the localization and the controller and can’t just copy a « component ».
And of course, there is no easy way to reuse common components instead of copying them.
I am not the first to question this issue with MVC and the Hierarchical model–view–controller (HMVC) has been introduced for this purpose, but how can we use such a pattern with XForms?
In fact, I m wondering if some of the innovative ways to develop XForms application which have been presented during the XML Prague 2013 pre-conference day were not more or less ways to deal with this issue.
For Orbeon Forms the way to deal with reusability issues is through XBL components.
XBL components cleanly encapsulate their own model/view/controller concerns but their development is highly technical and can’t be defined using Form Builder: you can use XBL components in Form Builder but you have to create them by hand and there is no way to just say « I want to define this group of fields as a new XBL component and use this component in other forms ». Such a feature would be most useful!
Another way to deal with this issue is to use a meta model and generate XForms. I am involved in another project which is following this path and you can expect to hear more about it in these pages!