Archive for April, 2008

Model Viewer Layout

One of the Form Guide developers produced a ‘Model Viewer layout’ which is used for debug purposes. It allows you to see the XML data of the moment, and even to change that raw XML and immediately reload it so you can test out various scenarios. It also shows you the XML data as a DOM and it also shows you the full Form Object model.

It’s easy to use, just drop it into the project for your custom SWC so as to make it available to Guide Builder. Then add a panel and assign it this Model Viewer layout. Navigate to that panel whenever you want to see the current state of things.

Disclaimer: This layout is provided "as is" and not as a supported part of the product.

Download ModelViewer.mxml

Including Info from any HTTP Header

Sometimes customers wish to transfer information from the context of the client session into the Form Guide. In particular, if the Guide is hosted inside LiveCycle Workspace ES, selected information that is in the HTPP Headers is desired to be made available to the Guide. This can be done.

Workspace ES provides all, yes all, not just a subset, of the HTTP headers to both the render service and the submit service. They are available to those services for any use that they see fit. Unfortunately there is an unexposed link in LiveCycle ES that makes this harder to accomplish. FYI: that link is properly exposed in LiveCycle ES Update 1. Nevertheless the feat can still be accomplished in LiveCycle ES.

Let’s say that you have an HTTP Header of special interest called ‘yourChoice’. We’ll go through the steps needed to have your render service ‘see’ that header.

 

First, in the render service, create a new process variable. I’ve called it ‘allHttpHeaders’. Mark it as type ‘map’, and mark it as an ‘input’ variable.

         allHttpHeaders

Save your updated render service. In your main process, open up the User Service step that references that render service. Examine the process’ Variable list. Naturally it will have a variable that is the ‘Document Form’ that is to be rendered. If you double click on that you will see something like the following:

          theGuidedForm

Now click on Advanced Settings … in order to see:

     AdvancedOptions

Because ‘allHttpHeaders’ was defined as an ‘Input’ variable it shows up in these options — begging you to map something to it.

 

ASIDE: BTW, since I’ve shown the above screen, notice the ability to put the User’s Common Name into a process variable that you have defined as an Input variable in your render service. I happened to name that process variable, a simple string, as ‘UserName’. Above you can see that there is a built-in source for that information under the ‘task’ group of items. This is a great way to get the actual Workspace ES user’s name into your form. This is often an issue since one can’t know which user will process the form until he/she actually chooses to do so (e.g. has taken the task from a group/shared queue). Using the above, your form can show exactly which user is processing the form.

 

Ok, back to extracting info from any HTTP Header. Your source for a map of all the HTTP Headers comes from the Custom Configuration area of data items. So change the default ‘xpath’ entry in the dropdown to Custom Configuration. If you click the "…" button on the right hand side you will see: <unfortunately>

     CustomConfig

Alas, there is no entry in there (in LiveCycle ES) that is what you want. ‘environmentBuffer’ gives you some of the HTTP Headers but not all of them. In LiveCycle ES Update 1 there is another entry in the dropdown named ‘httpHeaders’. That would be the one you want. In LiveCycle ES you are still able to simply key that in. You would end up with:

      httpHeaders

Great! Now your process is providing your render service with all of the HTPP Headers. Save your process, and re-open the render service. Ok, I could’ve done this all at once but I wanted to walk through the steps.

What I want to show now is how you extract information from the ‘allHttpHeaders’ map. You could stuff such data into the data file and have it rendered. You might use it in some other way in some other custom step of the render service. For now, I’ll just show extracting information out of the map and placing it in a simple string variable — which you can later use for any purpose you like. First we need that string variable as a place to store the HTTP header of choice. Let’s create a string variable with the name ‘myHeaderOfInterest’.

            myHeaderOfInterest

Not a lot to that. Note that it is a string, and it is neither ‘Input’ or ‘Output’. We don’t want it showing up anywhere begging to be mapped. It is simply an internal process variable for use inside this render service.

Now for the extraction. As usual we will use the standard SetValue operation to access the data elements in question. Drag on a SetValue operation; under the Properties tab add (+) a new assignment. The left hand side — the target location for the value assignment — is easy. Just use the [...] mapping button and double click on ‘myHeaderOfInterest’. The right hand side — the expression value to be set — is a bit more interesting. To start, use the [...] mapping button and double click on the ‘allHttpHeaders’ entry.

     extractingYourChoiceHeader 

After the double click you will have only the /process_data/allHttpHeaders part. You have to key in the [@id='yourChoice'] part yourself. There is no way, at render service design time, that LiveCycle can know what ids will be in the map at runtime and hence you have to specify that on your own. Of course, ‘yourChoice’ is a pretty unlikely name of an HTTP Header of interest but I’m sure you can supply, well, your choice
.

You will end up with a SetValue assignment as follows. Your chosen HTTP Header is in a string that you can work with as desired.

      mapOutTheYourChoiceHeader

   Add the HTTP Header context to your oyster.

/Andy

Video: Customizing form guides

You can customize form guides using the Guide Builder plug-in of the LiveCycle Designer ES software. With that you can select various built-in panel layouts and navigation styles. You can also choose from in-the-box form guide layouts as well as doing the usual styling, all without the need of programming.

This tutorial covers the creation of custom form guide libraries. It is about having your way with a form guide, making it ‘your own’, via Flex Builder. It is for programmers who want to create alternate guide layouts, alternate panel layouts, and alternate components to display data, alternate navigation mechanisms, and to inject custom business logic.

http://www.adobe.com/devnet/livecycle/articles/customizing_formguides.html