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#idMyFragment.
The relative uri limits the placement of referring 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?
Ive tried all obvious combinations of uris containing a repository or resource uri-scheme, like in:
Sorry, I didn't want to take too long explaining. But I already tried that way too, and it doesn't work either.
I saw a few pages on the net about referencing the repository, and that was one of the mentioned ways, but, that was only for using within the "Process Manager".
By the way, I tried specifying absolute file paths, like "C:\Fragments\Base.xdp", and they work.
I realize that relative "usehref" paths are more "robust" than absolute paths -- with relative paths we can open an xdp file both through the Workbench and through the Designer, as long as the relative position of files is maintained.
On the other hand, I really need to have pre-configured snippets of xfa in the Object Library, that have «usehref» attributes pointing to absolute positioned fragments in the repository, ready to drag-and-drop by our assumed "dummy" users.
My reasoning, in insisting to take this approach, is that it makes sense that such an absolute uri could be specified. Specially if, like me, one is trying to leverage the "inheritance" capabilities that the "usehref" supplies.
Unfortunately, apart from the aparent impossibility of specifying absolute repository uris, it seems that the Designer "doesn't like" «usehref>s that much. At the project I am working in, we experience constant designer crashes (the Visual C++ type ones included) while working with «usehref»ed objects. Things like «Copy&Paste» or, changing the order of «usehref»ed children, in the hierarchy, by «Drag&Drop> consistently cause the designer to crash. We don't know the exact pattern that causes the crashes, but can reproduce the error in certain identified documents.
I would be lying if I told you I wasn't expecting you to bring some light to these matters, as they have a significant importance on the mentioned project.
There is no support for an absolute reference to the repository in Designer. The relative references can be resolved because the server knows where the form was loaded from and can interpret accordingly.
I use absolute urls all the time with my forms and I have not had a crashing issue. There may be something else wrong. If you can duplicate the crash I would report it to support and see if we can iron out what it causing the crashes.