Re: [jbpm-dev] form builder - requirements request (+work in progress)

Hi guys, This is a quick update trying to describe the current status of the form builder project. I've being working the project for a week now and I've created a branch to do some big changes. I will quickly try to explain what these changes are and why I think that are important for the project. The following list shows the project modules that I'm trying to create inside the form-builder-split branch in: https://github.com/droolsjbpm/jbpm-form-builder -Form Builder API (already existing): as the name of the project mention, it will contain all the APIs to interact with the form builder functionality -Form Builder Model (new): this new module contains the models that are being used to represent forms and it was decoupled from the WAR and API modules in order to allow us depend on the model without being tied to all the form builder project as a dependency for the one that only wants to consume and render the forms that were created. -Form Builder Services (work in progress): I'm still working on this module, but once again, the services the get the forms and the tasks associated with a form needs to be decoupled from the Form Builder WAR module which is the authoring tool. The ones that wants to just render a form doesn't need to depend on the whole tool. -Form Builder (WAR) (already existing): This war needs to be clean up in order to only contain the classes that are used for authoring forms -Form Builder Consumer/Client (archetype probably/ new): we need to have clear rules and dependencies to be able to consume a form, no matter the technology that we want to use for rendering. In theory the consumer will use the Model and the Services + one exporter to render a form. -Form Builder Exporters (FTL/GWT): (already existing) the exporter projects have the mappings between the form meta model and each rendering technology. I will be focused on GWT and I will try to dig a little bit in HTML5 to see what can be done. At this point I don't know to much about these projects and their limitations. As you can see in the attached image, the services module interacts with an storage to do different things. One of the things that I will be adding soon is a service to manage the form builder settings. Until now, all the services were stateless, they do not store status in no way. What I would like to add is a way for the user to store their customizations and configurations in a persistent storage. At this point there are a two different things that can be stored: 1) Forms Structures / Form Item Structures / Human Task Structures-Information The form builder have a very cool feature to analyze Human Tasks structures that can be retrieved from a bpmn2 file and based on that generate forms. Those generated forms needs to be stored somewhere. Because they are knowledge assets, guvnor looks like the right place to go. I've implemented also a FileSystem support, to be able to use the FormBuilder without guvnor which makes our life easier to test the component without having the whole environment running. All this information is static and stateless in some way. We store and load these assets from Guvnor or the FileSystem using the existing services. (Adding support for a DB storage option probably make sense as well) 2) Settings / Customizations per user or role I'm planning to add a new service to manage and store settings for the form builder. These settings can be stored in a database, and I'm not sure that they can be considered as business assets. These settings are related to the user that is working with an instance of the form builder and want to customize its menus and for example choose if he/she wants to store if he/she was using the FileSystem storage option and a set of custom Form Items. As soon as I have the initial version of this service to handle settings I will be focused in creating a Generic Form Builder Consumer to demonstrate how you can use and integrate the generated Form with your own application. Hopefully I can get this working next week. If you have feedback about this points or if you have some features that you would like to see working in the form builder in the next month please write back. I'm eager to see how people wants to use this component. Remember that I'm working to get this component working in a "standalone" mode, so if you have another ideas about how to use it outside of the business process context please let us know :) Cheers -- - MyJourney @ http://salaboy.wordpress.com - Co-Founder @ http://www.jugargentina.org - Co-Founder @ http://www.jbug.com.ar - Salatino "Salaboy" Mauricio - _______________________________________________ jbpm-dev mailing list jbpm-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbpm-dev