Relative File Paths

[Dan Korn]

Originally Posted by jurgmay

I am now using both and will update my signature accordingly.

It still just says Windows, but feel free to go ahead and change it. Although my suggestion to put the version information in your signature is mainly targeted to users who are only on one platform, which is the most common scenario. In any case, when you're reporting an issue or asking a question, you should still specify the specific OS and FusionPro versions related to what you're posting, especially if your signature is going to list more than one version.

Originally Posted by jurgmay

Just out of interest - is there anything about file paths in the documentation? I looked and looked and couldn't see anything there that really explained it fully. I'm sure the answers I've got from yourself and Eric could be of real benefit to all FP users.

Well, I'm not sure about all users. This specific functionality of renaming your output file in JavaScript is an advanced feature which I would be surprised if a lot of people were using. And I'm also not sure that basic knowledge of how path specifications work, i.e. how many dots you need to denote a relative path, is something that needs to go in the product documentation.

In fact, you don't even need to specify a path at all (relative or absolute) to accomplish what you're doing here. Instead of specifying a path and file name with FusionPro.Composition.outputFileFullPathName, you can simply set the file name with FusionPro.Composition.outputFileName, and the output will go into the same folder as the output file specified in your composition settings. For instance:

FusionPro.Composition.outputFileName = fileName;

Now, going back to your original post, which was not really about changing the output file name in a rule as much as it was about just generally working with relative paths for things like resources, yes, there could be more clarification in the documentation about what kinds of relative path formats to use, if necessary. However, in a case like the example in your first post, you don't need any relative path specification there either. Let's go back to your original question:

Originally Posted by jurgmay

At the moment all my resources have to be placed inside the same folder as my template file which I'd like to avoid. What I'd like to do is have a folder within my template's parent folder titled 'Resources'. In my code I would reference it something like '~/Resources/' where the ~ will be the path to the parent folder of my template file.

Ideally my folder structure would be something like...

TEMPLATE FOLDER (Parent Folder)
INPUT (Child of TEMPLATE FOLDER)
OUTPUT (Child of TEMPLATE FOLDER)
RESOURCES (Child of TEMPLATE FOLDER)

All my resources would be places in the RESOURCES folder and all output files would appear in the OUTPUT folder.

It seems though that I have to either set the Search Path (through Compose > Advanced) or hard code the FULL file path. Both of these options mean I have to determine a static path rather than a dynamic one.

That's not entirely true. If you merely want to reference resources in a subfolder of your template folder, all you need to do is type that folder's name in the "Search Path" box on the Advanced tab of the Composition Settings dialog. Not a relative path with dots and slashes and such, just the folder name, i.e. "RESOURCES". That's all you need. Then any calls to file names in functions like CreateResource will automatically search that folder. The key here is that "RESOURCES" is a relative path; it's the same as "./RESOURCES" (or ".\RESOURCES", or even ":RESOURCES" in the old HFS-style specification on Mac).

You can also type other relative path specifications in the "Search Path" box. For instance, typing "../RESOURCES" there will reference a folder that's a sibling of your template folder. And ".." will reference the parent folder of your template folder.

Note also that you can enter multiple paths in the "Search Path" box, using semicolons to delimit them. So you can type something like "Graphics;../Graphics;../data" and all of those folders will be searched, in order (after the input and format/template file folders, which are always searched first, as I noted in my previous post).

We designed FusionPro to make it easy to locate resources and things without having to write any code or type path specifications, while still providing hooks for users who need more advanced functionality. (And for users with highly advanced requirements, we recommend FusionPro Server, which allows even more control over every aspect of the job through CFG file settings and other parameters than FusionPro Desktop.)

So again, to access resources from a subfolder of your main template folder, all you need to do is type that folder's name in the "Search Path" box. You don't need any dots or slashes or colons. For the output file, that's a little more complicated because you do need some JavaScript, but as noted previously, if that's also going into a subfolder of your template folder, you still don't need to type any dots or colons for that. So the whole thing about how many dots or colons or slashes goes away, and there's no need to document any specific path formats.

[jurgmay]

Dan - thanks once again for such a clear explanation.

I now feel completely informed about how FP handles paths and the way it references files. Very interesting to learn that I don't even need to use relative paths in the way I had assumed.

Please forgive me for banging on about the documentation - and I promise this is the last time I mention it - but I really think a brief explanation could be included.

Let me give some examples...

At the bottom of page 101 of the Rules System Guide it shows the following code -

FusionPro.Composition.outputFileFullPathName = "C:\\path\\" 
+ Field("name") + ".pdf"

The code and accompanying text imply that you need to hard-code the file path. I just think that an extra few lines condensing your last post would be really beneficial here.

Also in the section 'Help! The name of my graphics folder changed' on page 107 it mentions adding paths to the Composition Settings as you suggest but again it implies that you must hard-code the FULL path.

Do you see why I made the assumptions that I did? I'm just trying to point out to you how and why I thought I had to hard-code the paths. Whether you guys change the documentation or not makes no difference to me now but it could have saved a lot of time for myself, you and Eric if it was explained a bit more clearly. Also note that the two references above are in the 'Tips and Tricks' section which I think it's fair to say is what many would consider a more 'Advanced' section.

Anyway, look, I'm not after a debate - I'm sure we both have better things to do! In fact I'll make this my last post on the subject of documentation but I just wanted you to understand where I'm coming from and hopefully you'll see that I'm not just being deliberately awkward about this.

Thanks once again for all your input and clarifications.

Best wishes,

Juerg

[Dan Korn]

Thanks Juerg. I have entered case FP-11390 requesting that the documentation be updated to address the issues you've brought up. Sorry if I seemed argumentative; your concerns are completely valid. Thanks especially for those specific examples. Your continued feedback is appreciated and will help us to improve the product. Hopefully this forum will help to fill in some of the documentation gaps as well, so keep asking questions!

[jurgmay]

Originally Posted by Dan Korn

Thanks Juerg. I have entered case FP-11390 requesting that the documentation be updated to address the issues you've brought up. Sorry if I seemed argumentative; your concerns are completely valid. Thanks especially for those specific examples. Your continued feedback is appreciated and will help us to improve the product. Hopefully this forum will help to fill in some of the documentation gaps as well, so keep asking questions!

Dan - really no need to apologise. I'm glad the examples helped explained why I came to those conclusions and if it helps improve the documentation for other users then that's great.

Anyway, I've got the answers I was looking for thanks to yourself and Eric - and yes, I will certainly be asking more questions! (I have a few lined up already!)

Cheers for now,

Juerg

[jshobar]

Does anyone know if relative paths will work with paths to external data files?


matrix = new ExternalDataFileEx("/Users/UserA/Jobs/L142/Data/L142_matrix.txt", "\t")

matrix = new ExternalDataFileEx("../Data/L142_matrix.txt", "\t")

The former works, the latter does not.

I'm running 7.2 on OS X and my folder structure is:

-Jobs
--L142
---L142_Job.pdf
--Data
---datafile.txt
---L142_matrix.txt

[Dan Korn]

Originally Posted by jshobar

Does anyone know if relative paths will work with paths to external data files?

Yes, the Frodo Travel Tutorial uses a relative path with ExternalDataFileEx.

Originally Posted by jshobar

matrix = new ExternalDataFileEx("/Users/UserA/Jobs/L142/Data/L142_matrix.txt", "\t")

matrix = new ExternalDataFileEx("../Data/L142_matrix.txt", "\t")

The former works, the latter does not.

I'm running 7.2 on OS X and my folder structure is:

-Jobs
--L142
---L142_Job.pdf
--Data
---datafile.txt
---L142_matrix.txt

The path should be relative to the input data file. If the external file is in the same folder as the main input data file, then you don't need any path at all, just the file name.

[jshobar]

Thanks Dan! I wrongly thought it was relative to the PDF file, not the input file. Thanks for the clarification.