Submit or Execute on Other Events
I discovered something interesting the other day: Just because Designer wants you to type script for a field’s Full event doesn’t mean you have to execute script when the Full event is triggered.
The XFA 2.8 specification specifies the <event> node’s content as being one of the following nodes: <script>, <execute> (executes a web service data connection), <submit> (causes the form to be submitted via email or HTTP) or <signData> (causes the form to be signed). Only one may be specified and whatever content is there will be executed when the event is triggered.
This means that you could, for example, cause a web service to be executed whenever a repeatable subform’s index changes (i.e. whenever you add/remove instances).
Is this useful? Well, perhaps not, but I thought it was interesting! Who knows what you might think of doing with this…
The only catch to all this is that Designer only lets you enter script (JavaScript or FormCalc) into an event, thereby specifying an event’s content as <script> as opposed to <submit> or <execute>. If you want to, say, cause a form submit when a field’s Full event is triggered, you’ll have to go to the XML Source and set the event’s content to a <submit> node yourself. An easy way to do this is first to add an Email/HTTP Submit Button to the form, set the field’s Full event to a placeholder script, go to the XML Source view, find the button using the Hierarchy palette, copy its Click event <submit> node and paste it into the field’s Full event so it looks like what’s below and delete the button:
<event activity="full" name="event__full">
<submit format="xml" textEncoding="UTF-8" target="mailto:"/>
</event>Sample Form
Check-out my little sample form that causes the form to be submitted via email when you fill the text field at the top and where a web service data connection is executed whenever you add an instance of Subform2 using the button at the bottom (below the web service import/export fields).
Sample Minimum Requirements: Designer and Acrobat Standard/Pro 8.0 (XFA 2.5)
Posted by Stefan Cameron on January 30th, 2009
Filed under Events,Scripting,Tutorials,XFA
Both comments and pings are currently closed.
Hi,
I tried your form that connects to a web service. Generally we show forms in a web application and we don’t let the form or the web page connect to a web service on its own. We send a request to the web server and then the App. server( Spring or CXF ). Even though the forms server is deployed separately the control passes to our app. server.
How is this type of architecture implemented ? I couldn’t get any architectural guidelines dealing with Adobe e-forms and how it aligns with the established web application designs.
Thanks,
Mohan
Mohan Radhakrishnan,
While I’m no expert in that area, I would think that you could do it in many ways using LiveCycle. For example, you could define the web service data connection in the form but have it execute on the server rather than the client.
Depending on how your LiveCycle process was setup, another option could be to execute the web service call first, gather the returned data and merge it into the form when serving it out to the client (this way, the form doesn’t know anything about the web service).
Any pointer to a doc. on how the data connection hits the server(LiveCycle server ? ). Can I hit my app. server ? Actually none of these web service calls can succeed unless authorized and logged by my app. server first.
We plan to run the LiveCycle forms server on windows and our WebLogic app. server on Unix.
Thanks,
Mohan
Mohan Radhakrishnan,
There are 3 types of data connections: schema, database and web service. None of them would be hitting your LC server per se unless you exposed a web service from one of your LC services (built in Workbench). For schemas, it must be a local file or a resource in the LC Repository and for database, it’s via a DSN defined on the local system.
The DSN holds credentials for authentication and for web services, Designer 8.2 has basic support for authenticated web service calls (which you setup in the Data Connection Wizard).
Hi Stefan,
Could you please explain what is the difference between the “form:ready” and “intialize” events. I used to have the code to execute the web service in the “form:ready” event which worked fine and then it stopped working which does not execute the web service when there is no change in the web service. This happens after the LC ES service pack 3 was applied. So I moved the code from the “form:ready” event to the “intialize” and it works fine then. I couldn’t tell whether it the sp3 or the form, could you please advise.
Thanks,
Han Dao
Han Dao,
The difference between the Initialize and the FormReady events is that Initialize occurs immediately after data merge however prior to calculations and validations whereas FormReady occurs immediately after validations (so Initialize, Calculate and Validate events occur prior to FormReady). Both events occur prior to master page layout (which includes Initialize, Calculate and Validate for master pages). Finally, the LayoutReady event occurs, followed by DocReady.
It’s difficult to tell if it’s SP3 or your form without knowing more about the internals of your form.
i have been looking for days on how to do this. it looks like you have figuered this out but i dont quite understand live cycle that great i suppose. if i would like the web service to excute whenever the form event docready happens how do i make that happen i keep getting tons of errors and i cant get it to work? also when i download your form i noticed i dont see the scripting anywhere ?… any help would be appreciated.
Juan
juan,
To see scripts in a form, you need to select the object(s) who scripts you want to see and then use the Script Editor palette.
As for executing a web service on a FormReady event, I would recommend you simply invoke it programmatically by calling its execute() method: