Hello Stefan,

Nice to know you are putting your hands in this kind of projects.

Actually I believe this accelerators can be a great help for adobe livecycle users. I knew about them due to some questions I made to Adobe and livecycle users in general concerning a specific goal. I would like to share this goal with you, and get your always useful opinion, if possible.

I m evaluating the possibility of dynamically create a pdf/xdp form using a process in workbench. the steps would be like this:

1 – a designer would design a pdf/xdp in designer (workbench) and then create a formguide with it. This form would be only to get the necessary answers to evaluate process conditions.

2 – a process would be designed. The first activity would be to get a formguide and answer to its questions. The output of this activity would be the xml data of the form guide/pdf source. The next activities would run depending of the data in the xml. In each activity, and depending of the data, a new pdf/xdp form would be constructed, activity by activity. At the end I would get a new xdp file.

3 – When a user invokes the process (external application), it will get the formguide, the data is submited and the process continues. A new and final xdp/pdf file will be given to this user.

Do you think this is possible to achieve? Any recomendation?

Thank you

nep

Hello again Stefan,

The idea is to create a new xdp file based on previous created fragments. Given the data collected from the FormGuide, we would create, step by step, the new xdp file, by adding new fragments.

I think we could, and we will, begin the process from a default template, but I dont know waht you mean by using PIs. Any example somewhere?

Thank you

Hello Stefan,

I now understand the PIs solution, thank you. However, I think I will not be able to use them because I don´t know, at (template) design-time, how many PIs I will need. Because I only need to add paragraphs one after another, I believe I will only need to add this kind of instruction, one after another (in each process activity) to the xdp I will be creating:

What do you think would be the best approch to add this line of code to a xdp file in an activity? Do you think xpath would be the best approch?

Another question I would like to make is about the start of the process and more specifically formguides. I know that to create a formguide, one needs to have a template as a source. However, is it possible to delivery only the formguide to the user invoking it without delivering the pdf? I ask this because what I really need is the data captured in the formguide and not the pdf template. Thus the PDF template would only be needed to create the formguide and nothing more than that.

Finally, if I invoke a process using soap inan external application (Java or .net), is it possible to define a formguide as the first step (activity), in order to delivery the formguide as a soap response (maybe as a base64 stream), and then use it to invoke the second step of the process using that formguide (to submit the data) from the external application that received the formguide?

Thank you again

Stefan,

The code I was trying to show here was actually your own code from a previous post. The idea was to add one of this line in the final xdp, based on the avaliation rules about which fragments that final xdp should have. I think this should be something easy to accomplish…

<subform usehref=”../frag/main.xdp#som($template.#subform[0].fragSF)”/>

About form guides, you are saying that form server will reply a stub to the formguide. This was confusing me, because I was seeing the reply as a base64 stream ripped from the xdp of the source template. What I was not understanding was how all those javascript files used by formguides would come from. If that stub is something like an html link, then I think I understand how it will work. However, if you know someone that as done this, or any example elsewhere, please let me know, becuase that would be a great help.

With this formguide, I would like to invoke another livecycle process, passing it a xml stream of the data. That way I will not need to create a custom screen/form in any other technology. However, the call to the formguide should be done using a java/.net client, that is why I need to retrieve a formguide from livecycle. I know I could use workspace as the client, but I would like to have other alternatives.

Thank you

Hello Stefan,

Using some steps in process, I was able to create a xfa template held in a xml variable. This xfa template has some fragments with relative urls to the repository. However, when I tranform this xdp template into a pdf it seems my fragments are not being resolved. I think this happens because there is not a position context to this xfa template in the repository as it was created dynamically. As so, do you know another way to point to the repository fragments without depending of the location of the main template?

thank you

nep,

With regards to your first comment (on Jan 8, 2009), I believe the template you create will need to be stored in the LiveCycle Repository prior to being rendered as a PDF. Otherwise, the render service will not be able to resolve the fragments, as you’re seeing in your test.

This is where the Correspondence Management SDK could help you out since the CM Model API has classes that can create assets directly in the LC Repository. The only problem here might be that it’s written in ActionScript and I think you’re using Java — not sure.

In any case, here’s how you would use the API to create a new generic form resource, stuff your dynamically-generated template content into it and save it to the LC Repository using the currently-posted release:

import cm.model.CmObject;
import cm.model.CmSession;
import cm.model.repository.CmResourceType;
import cm.model.repository.CmRepositoryEvent;
import cm.model.repository.CmRepositoryFactory;
import cm.model.repository.CmResourceCollection;
import cm.model.repository.ICmRepository;

private function onBtnClick(event:Event):void
{
    // create a new generic form template resource object
    var xdp:CmObject = new CmObject();
    xdp.resourceType = CmResourceType.FORM_TEMPLATE;
    xdp.path = "/cm/content/myForm.xdp";
    xdp.contentType = "application/vnd.adobe.xdp+xml";
    xdp.contentData = '<xdp><template><subform name="root"><subform name="page"><field/></subform></subform></template></xdp>';

    // make sure there's an active, authenticated session
    if (CmSession.getInstance() == null || !CmSession.getInstance().authenticated)
        CmSession.createInstance(username, password, server, port);

    // get an instance of the LC Repository
    var rep:ICmRepository = CmRepositoryFactory.getInstance();

    // save it in the LC Repository
    rep.save(xdp, true, onSave, onSaveFault);
}

private function onSave(event:CmRepositoryEvent):void
{
    Alert.show("Saved XDP to LC Repository");
}

private function onSaveFault(event:FaultEvent):void
{
    Alert.show("Error occurred while attempting to save: " + event.fault.toString());
}

I am using LiveCycle Workbench to design xdp documents. We reference fragment xdp documents from the repository and also we have the “usehref”, directly used on field.s, draw.s, to inherit behavior from a common xdp at the repository.
We use something like this: usehref=”..\Fragments\Base.xdp”.
The relative uri limits the placement of refering documents relative to the common xdp (unless, of course we would change the relative path accordingly, but we have fixed templates in the object library , so we would like to avoid that).

Is there a way to use absolute uris, in the usehref attribute, to reference documents in the repository?

I’ve tried all obvious combinations of uris containing a “repository” or “resource” uri-scheme, like in:
repository://Base.xdp

Thanks in advance

Duarte Cunha Leao,

Yes, you can reference fragments in the LiveCycle Repository using an absolute path. The path must be in the form of

repository:///root/path/form.xdp#fragRef

where “root” is the root folder in the Repository in which the content is located, “path” is the intermediate path from the root to the content, “form” is the XDP that contains the fragment to be referenced and “fragRef” is the ID or SOM reference to the fragment in the form.

Note the 3 slashes following “repository:” in the path above. If you specify only two (2), the first element in the path is considered to be the “authority” but this syntax is currently not supported.

Also note that “repository:///” paths are not resolved by Designer which means that when you go to the XML Source to set the absolute path and go back to Designer’s “Design View” or “Master Pages” tabs, you’ll see a broken fragment reference instead of the actual (resolved) fragment content.

LiveCycle Forms is therefore required to resolve “repository:///” paths. When you render your form using LC Forms, the fragments will be resolved properly.