Highlighted

Absolute uris in "usehref" for repository fragments

Avatar

23-01-2009

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:

repository://Base.xdp

Replies

Highlighted

Avatar

Avatar

pguerett

Total Posts

7.7K

Likes

611

Correct Answer

692

Avatar

pguerett

Total Posts

7.7K

Likes

611

Correct Answer

692
pguerett

26-01-2009

Try it with three slashes:



repository:///Base.xdp
Highlighted

Avatar

26-01-2009

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.



Thank you very much for you help
Highlighted

Avatar

Avatar

pguerett

Total Posts

7.7K

Likes

611

Correct Answer

692

Avatar

pguerett

Total Posts

7.7K

Likes

611

Correct Answer

692
pguerett

26-01-2009

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.
Highlighted

Avatar

27-01-2009

I sent to livecycle8@gmail.com the xdp files that cause the crashes on my machine.



Relating to the absolute uri in usehref question, I'm afraid you're right. Your fellow Stefan Cameron confirms that too on a reply to a comment I put at:

http://forms.stefcameron.com/2008/06/19/correspondence-management/



This is quite unfortunate because Forms Server does support those uris, but the Designer cannot show/resolve them. Which is the same as not being able to design after all...