Here are my thoughts.
It is correct that the custom render service needs to be bound to the Form.
But you can obviously use that one custom render service for multiple Forms (in same/different Long lived orchestration) and have branches in your custom render to do different type of pre-population based on form name. This will allow you to do different field pre-population based on the form name/type that is being opened.
Usually, in an enterprise deployment of LCES I would expect the same form fragment being used in all forms that need user details being pre-populated. In this scenario all of your long-lived orchestrations will have the Form/xfaForm variable using that render service so the LDAP query and data injection puts the data at same/correct place in the form.
To me, one custom render service for pre-population that you can use across the all forms seems possible and would be advisable too. But there is obviously the flexibility of doing form specific things in that same custom render process.
Thanks Parth, perhaps I'm not understanding entirely. If you take a look at Seth's example from my link in my original post, his render process uses an xfaForm variable that has to drill directly to the form. That tells me that each render must point to a specific form, which means you need a render service for each form.
However, I imagine that the render service can point to a fragment xdp file, right? So we can always populate the fragment and use that fragment on the form. ... hmmm... maybe I am understanding it after all.
Thanks for your reply!
You wouldn't want to render just a fragment (that does not make sense to me).
The fragment is an xdp and the form is also an xdp (xml format of a designer template). When you add a fragment to a template there is a link put into the main template referencing the fragment (like an include statement). When you render the template all of these links are resolved (getting the xml that represents the fragment and putting then into a common xdp template). That temp template is passed to the render service and it in turn turns the temp template into a PDF for you. This architecture allows you to modify the fragment source then whenever a form that uses that fragment is called the "NEW" fragment is included in the file.
Hope that helps
Thank you, Paul, I understand, but only slightly. When you use the term
"template" are you specifically referring to a form template created in
designer? Which leads me to another question, when you create a form based
off a template, and the template changes, does the form change too, to
inherit the changes from the template which it is based?
The topic of prepopulating continues to elude me. Either I'm just not
getting it or it's less intuitive than I think it should be. I'd like to
have a standard set of fields that are prepopulated on a form, but I'd also
like to have the ability for form A to prepopulate using the standard set,
while form B prepopulates a subset, while form C prepulates the standard set
and additional fields (a superset).
Are there working examples of such? Jochem pointed me to the FormsIVS
samples for an example, but I'm finding that perplexing as well.
Thanks very much for your input,
1 person found this helpful
Yes when I say template I mean the form that is designed in Designer. Usually a template is stored in its native format (XDP) and a server program like LiveCycle Forms (aka Form Server) will interpret it and turn it into a Form (PDF, HTML, Guide etc) in real time. Because this is happening "OnDemand" if changes are made to the template before the render occurs then all changes made to the template are incorporated in that rendition of the form.
Form Server can also combine data with the form when you ask it to render. The data must be in an xml format and if the bindings of the form to the data are set up correctly then you will see data in the form as it renders. Each template can have its own data structure or can work off of a common data schema. In your case a common data schema woudl be recommended. This allows you to create your pre-populated data for Forms A, B and C in the same structure and by simply passing the data file to the Renderer you get the desired result. FormsIVS is a good test app to make sure you have everything setup correctly. You can create the structure for the data then add your form and call FormServer in real time to see the result.
One last thing, to get the structure of the data you can simply export a data file from the form and it will have the structure that the data needs to be in.
Hope that helps
Thank you, Paul, this is very helpful. I really need to understand exactly what goes on during the render process so I will do some research further.
Thanks again for your help!