Hi
We have an existing form designer. So until now we have hooked up forms merely by form key attribute, look them up in our own database. But I was wondering how easy it would be to have our own forms in xml format managed by the flowable form engine in the standard flowable table structures to make the deployment a bit more cohesive?
The Flowable form engine stores its forms as JSON, so you could probably find some way to customize it to use your designer and runtime. We then bundle the process, case and form models into an App thaht can be deployed as a bundle (it’s a zip - so like BAR files) - form models are not embeded in the BPMN XML.
Cheers
Paul.
Yes sorry, I familiar with some of how the current form engine works where I was using the built in forms. I am more thinking along the lines of a custom form engine implementation, where it deploys our xml files instead of the current form engine json.
It’s almost like wanting to implement our own form engine, but we actually wouldn’t mind reusing the infrastructure as in the same table structures and concepts as in the current form engine, except the way the fields are structured and represented is different (we have fields like barcodescanners for Android, tabs, etc). So I was hoping there were some targeted API’s we could override/extend/replace.
But from what I have seen so far the form-model library’s classes are found in many modules, so I was looking for some pointers or indication of feasibility. Broad ideas like how to get it to pick up xml and not care about whatever current validations there are and how to create own GetFormModelWithVariablesCmd.
But even more so, someone saying to me, hey I think it is simpler to just keep them separate not feasible to go down this route 
Flowable’s commercial Forms offering provides an alternate forms engine implementation. There is a significant amount of code involved, it would not be a trivial project. Unless your core business is maintaining a forms engine, you’re probably better off keeping them separate.