I'm working on a form that goes from one user to another. It's a fairly large and complex form (about 7 pages) with calls to multiple web services.
After the form is opened and some information is populated into the fields, a user will be able to change the values of some fields, and then will submit the form. The next user in the process will get the form and open it up from his/her To-Do queue. The fields with the changed values (changed by the previous user) would need to be visually identified to this next user. When that user finishes working on the form and submits it, it is opened by the next user in line. and the changed information STILL needs to be visually identified. We have found it is easy to highlight a changed field while a user is working on the form (using the change event) but it is more difficult to make that highlight stay visible all the way through the process as different people get the form. I thought about making a hidden field for every field in the form and compare the values in the validation event. but this would effectively double the size of the form and all those hidden values would need to be included in the XML schema (doubling the size of the XML schema).
We would appreciate ANY assistance on a proper approach.
If you are changing the background color then that shoudl be maintained throughout. In Designer on the File/Form Properties/Defaults tab do you have the Keep scripting changes checkbox set on Automatic?
Thanks a lot for your prompt answers! The keep scripting changes checkbox on the Default tab is set on Automatic, will give this a try and let you know if the fillColor of changed fields is visible through the diferent states of the form and to all users fo the form.
Sorry so late to get back to you. Thank you for your suggestions. I did the test, but unfortunately the fields that were changed by one user and therefore highlighted, were not highlighted when the form was received and viewed by the next user. Any other ideas?
OK, can you give me a little more info on how the workflow is implemented? When the user submits the form, is the entire PDF submitted or just the XML data? When the next user gets the form do you re-render the form combined with the XML data? Is the XML data persisted between form renderings? And, do any of the web services that are called store data related to each specific form, or are they just fetching generic data to be displayed?
The form is originally filled out let's say by the "Originator". When the originator sends the form, it goes for approval to other users in different stages (e.g. if "Approver 1" approves and sends the form, the form then gets to "Approver 2", etc. When any user submits the form, only the XML data is submitted, then when the next user gets the form the form is re-render and combined with the XML data. The XML data persist between form renderings and the web services are only fetching information from a data base for display to the user. The idea is that the Originator will see the form with all the data (retrieved from the data base by a web service) in the different fields and will make the necessary changes. When a new value is entered in any field, the field will be highlighted. Then, when the "Approver 1" gets the form, he/she must be able to visually identify the fields/data that was modified by previous users. Hope this makes things clearer!
That does make things clearer. You will have to save the change information in the XML. I realize that you don't want to save an xml node for every field, but there is a better way. You can use scripting to add data nodes to the XML data in the form. I'm thinking of the following:
Include an empty container node in your XML schema: <HighlightedFields></HighlightedFields>
When a field is changed, in the field's change event call a common script: HighlightChangedField, passing in the object. The script will highlight the field (set the border a certain color or whatever). It will also add node underneath the HighlightedFields data node with the SOM expression of the field. The SOM expression is the "path" of the object in the form heirarchy, sort of like an xpath. So if you have a subform named Subform1 and you change the Name and Address textfields, you might end up with something like:
The upside of this is that you only store XML nodes for what is changed instead of needing a specific XML node for each field. The downside is that you will need a call to the common script in every field's change event: HighlightChangedField(this);
Now, to make this work when a form is loaded the next time, in the initialize event at the topmost subform in the hierarchy you add a script that walks the HighlightedFields data node, and for each HighlighedField entry you highlight the contained object. You can get a reference to an object using its SOM expression, so just take the SOM expression from each entry and do an xfa.resolveNode(SOMExpression) to get the object, then set whatever attributes you want to highlight the field.
The big issue I see with this would be if you have dynamically added objects on your form. In that case you would probably need to store the instance index along with the SOM expression for each changed object, then use that instance number when highlighting on form load.
I don't know how much you know about scripting, so I hope the above makes sense. If you need more help I can try to mock something up.
Your idea makes sense, that way a node will be created on the XML only if the value of that field was changed! I'm fairly new to scripting in Java Script for LiveCycle and although I get the big picture of what you are saying, I would greatly appreciate if you could provide me with an example!
Europe, Middle East and Africa