Greetings from Argentina. This post will try to cover a general view of where the form builder is right now and where it is going to be in the near future. You can get a current status view from the video below:
On this video you can see a great deal of how the form builder works today. It doesn’t cover the jBPM console integration part or the automatic form generation option, but it allows you to see how users will experience working with the form builder. To download the project, you can find it in the following locations
Nightly builds
In the next few days, I’ll start keeping a stable release on this other address as well:
Feel free to download, comment or join. That pretty much covers where the form builder is right now. As to where it is heading, here’s an initial roadmap
jBPM Form Builder Roadmap
- Adding HTML5 templates: Current items work with pure GWT and HTML4 for Freemarker. The idea is to build a new renderer that will allow users to export to Freemarker as well, but allowing them to export using HTML5 instead of HTML4 to create the forms. The idea as well is to create as many menu options to properly cover HTML5 capabilities, such as audio and video tags, menus, fieldsets and so on.
- Adding new validations: Current validations cover basic concepts, like number or email validation. The idea is to expand and improve validation definitions, in order to allow both client side and server side validation to any level of complexity. Among new validations that are thought to be added, there will be regular expression validation, multi-field validations (applied directly to the form), and rules-based validation (in order to define a ruleflow-group specially to validate the correctness of input data)
- Adding script helpers to add dynamic ui components on client side: Script helpers are shown in the video above. They allow a user with very little knowledge of javascript to create scripting solutions for UI component’s event handling. The idea is to create a new script helper to allow javascript to add a new visual component on a particular layout and layout position when an event happens.
- Cleaning up effects and form items library: Current implementations of form items (the UI components you drop on your form) and form effects (the actions available when you right click on a form item) are done in a way that could be made configurable with a proper refactor. The whole idea is to make it more easily extensible, minimizing the amount of code to be added to create a right click action for UI components, or a UI component itself.
- Adding tests for effects and form items library: Along with the previous item, some refactoring will be made to allow a better separation of display logic from actions logic, in order to create better test prepareness on the code side. Along with that, proper tests will be implemented for the form items and effects library.
- Adding server validation to the generated form’s API: Extension of the form utility API used from jBPM console, to handle validations on server side.
- Adding server interpretation of complex objects to the generated form’s API: Currently, all form submit responses are treated like a map of simple data. The idea is to create complex object associations to particular paths in the form definition, in order to create the proper objects on submit time. This will benefit both user task definitions and rule-based form validations.
- Adding template management for complex objects for the generated form’s inputs: The previous item covers submit to server rendering of request data, from simple data types to complex data types. This item covers the other way around, for when a user task is given a complex type and needs to decompose it to make it available for form input data. It will allow the user to define paths within an object when defining form inputs.
- Improvement of properties edition panel to add better coverage of properties for form items: This comes in hand with item 4. Once a proper management of form item properties is done, there will be a need for a better way of editing such properties.
- Improvement on tree and edition panel visualization: Bug fixing and visual highlighting in the current form are two of the main things to be tackled by this bullet.
- Allow switching layouts once they’re filled without losing content: Currently, once you define a layout and start adding content to it, the only way to change layouts is to create a new one and move all the content manually. This item is thought to be able to do that automatically.
- Adding script helpers to allow onEvent simple validations on client side: Along with validation library expansion and server validation API, this item is thought to allow some validations to happen on the client side, to be handled on particular events (i.e. like on the change of value of an input field)
- Pagination items: Create UI components that would allow to create very large forms within several pages, all part of the same form.
- Definition of a standard page layout for a given user or role: Most companies have a template structure for most of their forms (wether it has a logo on a particular place, a standard stylesheet, etc). The idea is to allow designers to define such page layout and force its use to either some people or a group of people within the company.
- Definition of standard UI visualization strategies for particular types of data: This is to aid the automatic form generation. The idea is to allow users to define, for example, the standard way to create visual content for Strings, Integers, Booleans and so on. It should cover complex data types as well.
- New translators and renderers for JSF, XUL, Android, IPhone and Swing: Among other technologies, this would be a nice subset to cover. The order of the technologies and the omission of any don’t express any priority whatsoever.
- Adding effects to allow loading contents from an ajax script or from an array variable: This way, content from a form could be loaded from an external source from the client side.
- Importing of inputs from other external sources: Right now the only way to import inputs on the IO Data tab is to have them defined inside a BPMN2 process. The idea is to be able to take them from a server invocation, a user file, or any other way. This will also allow to define forms for other platforms different than the BPM engine.
Cheers,
Mariano
