6 Replies Latest reply on May 26, 2009 7:24 AM by Amal Elaine

    Does pre-populating mean you need a unique render service for each form?

    Amal Elaine

      [xpost from google livecycle group]:


      So I'm revisiting the art of pre-populating a form.  You know, the concept that is really trivial in most applications except livecycle....

      [exit jab mode ]

      In three internet posts/examples that I saw, each had the render service tied specifically to "the form" that is being pre-populated.  Kind of makes sense, because you have to poke the data into the specific form, right?

      But that has me thinking that now the render service can no longer be used across multiple forms because you have to reference "the form" to poke the data into the form's field.  Now it appears that each form will require its own render service in order to prepop.

      Am I understanding that correctly?  If I am, what is the impact on performance if each form needs its own render?

      At this point I'm thinking that writing a short-lived custom component using the LDAP api's and populating the form upon form initialization might be a preferrable approach.

      Here are the sites I researched:
      Roland Lopez:  http://www.roland-lopez.com/tech/
      Seth Riley: http://livecycleapps.wordpress.com/2009/01/29/prepopulate-form-for-display-in-workspace-an d-route-it-to-another-user/
      ES Lifeline:  http://eslifeline.files.wordpress.com/2008/05/renderservicefinal.pdf

      Sing me,
      All rendered out,


        • 1. Re: Does pre-populating mean you need a unique render service for each form?
          parth pandya

          Hi Elaine,


          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.



          Parth Pandya

          Blog: http://livecyclekarma.wordpress.com

          • 2. Re: Does pre-populating mean you need a unique render service for each form?
            Amal Elaine Level 1

            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!


            • 3. Re: Does pre-populating mean you need a unique render service for each form?
              pguerett Level 6

              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



              • 4. Re: Does pre-populating mean you need a unique render service for each form?
                Amal Elaine Level 1

                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,


                • 5. Re: Does pre-populating mean you need a unique render service for each form?
                  pguerett Level 6

                  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



                  1 person found this helpful
                  • 6. Re: Does pre-populating mean you need a unique render service for each form?
                    Amal Elaine Level 1

                    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!