Author Archive: Mick Lerlop

Updating Hostname of WSDL Connections in XDP with LiveCycle Form Rendering Process

A lot of times form developers develop form designs locally on their machines or on development servers. When dealing with web services, they would use the local or development instances of the web services by creating data connections pointing to WSDL URLs on localhost or dev.server.com. This is perfectly fine until the forms need to be migrated to other systems such as system test, stating or productions. The form developers would need to revisit the forms and update the data connections to point to the appropriate URLs depending on which environment the forms are being migrated to.
This becomes a big time consuming issue on projects dealing with a vast amount of form designs. So recently what I have been recommending my customers is to use a form rendering process that updates the WSDL data connections in the form design automatically on the fly as the form is requested by a user.


How does this work? (Please also refer to the process map below.)

  • The process reads the requested form design resource from the LiveCycle repository.
  • It then copies the content of the form design as XML to process variable and counts the number of WSDL data connections in the form.
  • Then it loops through every WSDL connections and update the domain name including the port with a new domain name extracted from a process variable called targetURL. (This targetURL variable is passed in automatically when you set up your the Render Service setting in your form variable.)
  • It then updates the form design variable with the new XML that has new WSDL information.
  • Finally LiveCycle renders the form design into a PDF. 
wsdl-updating-form-rendering-process.png

Requirements

  • LiveCycle Forms ES server.
  • The form design has to be in an XDP format.
  • The XDP has to be in the LiveCycle repository (e.g. database, Documentum, FileNet, etc.).
  • All web services used in the XDP have to be on the same server as the LiveCycle instance.
  • The only difference between web services on various environments must be the domain name and port. (e.g. http://dev:8080/soap/services/Weather?wsdl and http://staging/soap/services/Weather?wsld – OK but http://dev:8080/soap/services/Weather?wsdl and http:/staging/soap/services/Weather2?wsdl – Not OK)
Download

Download wsdl-updating-form-rendering-process.xml
and import the XML into LiveCycle Workbench as a process.

Further thoughts
  • If you need to reader extend your forms, add a Reader Extensions action at the end of the process map.
  • If your form design is in PDF, you could modify the process map to read the PDF resource from the repository and convert it to XDP.
  • What if you only deploy PDFs to your production system and don’t want to render them only the fly? You could render XDPs to PDFs as a batch process by creating a watched folder endpoint that invokes this form rendering proess.

Dynamically creating a table with data in LiveCycle form using JavaScript

Stefan Cameron wrote an article on scripting table columns a while back. Taking that idea, how would you dynamically create a table based on some data? Well, there are a couple of ways and this blog post will show you one way of achieving it.

Continue reading…

Generating JavaScript Documentation for Script Objects

One of the things many developers often fail to do is to document their code. Code and documentation comments are not only useful to yourself but also to other developers who may have to contribute to your work or use your work as part of their work. They help increase maintainability, code readability and ease of use. As previously posted, you can create script objects in Adobe LiveCycle Designer to extend standard JavaScript classes with prototype functions and properties. Your script objects can then be distributed among teams for reuse. However, if your script objects contain a large number of functions and properties, your end users may request for documentation.

Continue reading…

Using JSON to Exchange Data with Web Services in XFA Forms

Continuing from my previous post on extending the JavaScript prototype property, another most under-utilized technique is the use of JavaScript Object Notation (JSON) as a data exchange format between a form and web services. Did you ever think of using JSON in form development? No? Me neither. I never thought of it until one of my customers suggested the possibility. It was an elegant solution, as our web services were getting more complex, we were wrestling on reading the data versus implementing solutions. JSON gave us a way to reduce hassle of working with complex objects.

Continue reading…

Extending JavaScript with Prototypes in XFA Forms

Do you sometimes wish you had functions that standard JavaScript does not provide? For instance, a trim or strip function that removes leading and trailing white spaces from a string object. In LiveCycle Designer, the traditional way is to create a script object and a function. Then to use it, you would have a function call similar to the following statement:

var newString = ScriptObject.trim(oldString);

These function calls can become lengthy in situations where the script object is located on a different page than your method call. For example:

var newString = form1.page1.subform1.ScriptObject.trim(oldString);

Continue reading…

Acrobat 9 is shipping and Here is how to communicate between PDF and Flash/Flex

Prior Acrobat 9, we were able to communicate between a PDF and a Flash/Flex application residing in the same browser window (e.g. the iframe approach). Acrobat 9 introduces a new feature called Rich Media Annotation that allows you to amazing stuff with Flash … one of them being the ability to embed Flash into a PDF and communicate with it via JavaScript. The example here is simple PDF document with an embedded Flex application that takes a product ID from the PDF and queries Amazon Web Services for product information (features, price, release date etc.).

Continue reading…

Using Image in Acrobat JavaScript Dialog

I have had customers asking about how to brand Acrobat JavaScript dialog boxes with images in Adobe LiveCycle Designer. I did some research and found that it was not as simple as defining an <img href=”image.png”/> tag (I wish it was that easy though). As an overview, images used in a Acrobat JavaScript dialog has to be in a icon stream format represented by a hex-encoded string. The data string also needs to be 32 bits per pixel with 4 channels (ARGB) or 8 bits per channel with the channels interleaved. The hex-encoded string looks something like this, "fffffffffff…efdf8fff0e3beffd3b". Beautiful. Anyway, moving on.

There are a number of free and commercial third party tools you could use to convert images to hex-encoded strings. However, none of the tools fits my workflow in terms of flexibility and extensibility. So I have created a Java utility library, called Acrobat Dialog Image Generator (ADIG), which allows you to generate a hex-encoded string or a skeleton Acrobat dialog box with an embedded image.

You can invoke ADIG via a command-line interface, ANT or an API call. Here are some sample invocations:

Command-line

java -jar adig.jar /Users/lerlop/Pictures/test.jpg /Users/lerlop/Desktop/

This will reads in test.jpg and generates a JavaScript dialog file called test.jpg.txt on my desktop. Here is a sample.

ANT

ant -buildfile adig.xml

This will also produce the same result as the command-line option but everything is defined in the following build file.


<?xml version="1.0" encoding="UTF-8"?>
<project name="MyProject" default="GeneratorAcrobatDialogImage" basedir=".">
<taskdef
name="adig"
classname="com.adobe.consulting.ant.tasks.GenerateAcrobatDialogImage"
classpath="../../build/adig.jar"/>

<target name="GeneratorAcrobatDialogImage">
<adig imagePath="/Users/lerlop/Pictures/test.jpg" outputPath="/Users/lerlop/Desktop"/>
</target>
</project>

API Call

String hexString = AcrobatDialogImageGenerator. generateHexEncodedString(imagePath);

By calling this static method in your Java code, you can generate a hex-encoded string from an image and assign it to a String object. This particular option is very useful when you try to perform any kind of batch operations. For instance, I can call this method to dynamically insert an image to a JavaScript dialog defined in an XDP before calling LiveCycle Forms to render it as a PDF.

To use the generated dialog JavaScript code in your form design, you can follow these simple steps:

  1. Run ADIG via command-line or ANT to get a generated file. The generate code should like this.
  2. Open your form in LiveCycle Designer (note: XFA form not AcroForm).
  3. Create and name a new script object. It does not matter where the script object is located as long as you can reference it later. For simplicity, create it on page 1 and let’s call it DialogSO.
  4. Copy all the code from the generated file and paste it into the script object.
  5. Now create a button object so you can use it to launch the dialog box. Note that you could launch the dialog box in any event such as form::docReady or form::initialize.
  6. The last thing is to make the button launch the dialog box. In the click event of the button, type in the following function call: DialogSO.launchDialog();

There you have it. You can extend the dialog box in any way you like by adding dialog elements to the dialog body. Please refer to the JavaScript for Acrobat API Reference.

I want to note that there are commercial tools out there that will let you design and extend Acrobat dialog boxes far more than just adding an image and generating dialog JavaScript template. If you are looking for a WYSIWYG tool to design dialog boxes, WindJack’s AcroDialogs may be more suitable for your needs.

Downloads: