- February 1, 2011 at 9:54 pm #683
I am wondering if there has been any successful cases of multiple people developing and working on the same form collaboratively in order to deliver a complex form project? Or is there any easy way to merge or migrate form and workflow components from different developers into one master form, and is this a recommended approach? Thanks.February 8, 2011 at 2:32 pm #5596
If its possible for your environment, I would recommend using “satellite forms”, thats a term I use to refer to forms which interact around a main central form.
So for example, if you wanted to make a Purchase Order Form, you design one central form, which basically just contains fields to store data, and has status markers fields like APPROVAL STATUS, RECEIVED STATUS.
Then you can get one developer to work on a Create Purchase Order form, which does all your fancy behaviours and permissions and calculations and notifications and whatever, and at the end of the form, you do a show form behaviour to create a new instance of the central Purchase Order Form, sending custom parameters that will uniquely identify that form, and the action that is being done (action = NEW). That form will have a Form Is Opened Behaviour, which will get and store the custom parameters, and if the custom parameter = NEW, then it will just submit and close, in order to create itself.
Then you connect to that form, or use “set field in another instance” and write in all the values from your Create Purchase Order form, writing to the status marker fields: Not yet approved, Not yet received etc etc.
The next developer will work on the Approve Purchase Order Form, which will search for the form by the unique identifier, or search for all forms that comply with Not Yet Approved, and place the results in a table, which has a button to process the current row. His form will suck out the neccesary info (using connections or Get Fields from Another Instance), and allow the appropriate people to make the appropriate decisions, do notifications etc etc and then send back the relevent info to the form, changing the status to Approved/Declined.
The next developer can create a form that searches for the specific instance, or for any instance with Approved, Not Yet Received. They then suck out the relevent info, and do a process to receive the order, and then send back the neccesary info to the central form, changing the status fields to Approved, Received and so on.
So basically, instead of having one huge form with loads of behaviours, you have have different forms for different actions, and developers can each work on their own satellite form.
You must be logged in to reply to this topic.