Resolving relative pathnames in an XML discussion

[Lynne A. Price]

Trevor-Nicholls started a discussion last month on creating an XML document from the welcome screen (Re: Creating a new document from the Welcome screen, doesn't ). That discussion has grown to include several related topics, so I am splitting my responses in new discussions specific to individual subtopics. This is the fourth such new discussion.

Trevor, the temporary files used for XSLT output in a pre-process and for XSLT input in a post-process are stored in the users %temp% directory, not the directory where the input or final output is stored. If you do not want to use absolute pathnames, or if you want different paths for different users, consider defining a parameter in the Preprocessing element to contain the directory name.

    --Lynne

[Trevor-Nicholls]

Hi Lynn

At first I thought this was a great idea - a parameter in the pre-processing stylesheet would provide an elegant solution to this problem. It proves not to be so, alas.

In structapps for this application we have

DTD:       $STRUCTDIR\xm]\testing\app\test.dtd

XSLT Preferences:
  Preprocessing:
    Stylesheet Parameters
      Name:            DefaultDTDPath
      Expression:    $STRUCTDIR\xml\testing\app\test.dtd
    Stylesheet:      $STRUCTDIR\xml\testing\app\test.xsl

$STRUCTDIR is treated as a variable in the DTD and stylesheet lines, and is replaced by the actual path. But it is treated as a constant in the parameter expression, which defeats the purpose. (The console reports an XML parser error: unable to open DTD document $STRUCTDIR\xml\testing\app\test.dtd.)

If I could specify the parameter value as a constant then I wouldn't need the parameter because I could put the same constant in the stylesheet in the first place 🙂

It's either got to understand and replace $STRUCTDIR, or it has to allow some other environment variable in the expression.

It seems this isn't possible.

Cheers
T

[Lynne A. Price]

Trevor,

   Yes, $STRUCTDIR is a convenience FM provides within the application definition file.

   If I've understood your requirements, you want to be able to set up multiple users on multiple computers to use the same application and have access to the same files. You currently have changed $STRUCTDIR to a directory within  %appdata% so that everybody's definition of $STRUCTDIR is different. There are ways to make that organization work, but it might be easier to change things a bit.

  In particular, I suggest trying:

1. Restore the default $STRUCTDIR by removing the line in maker.ini that redefines it.

2. Restore the original structapps.fm in $STRUCTDIR.

3. Create a new directory outside of Program Files where you will store your application files, e.g., c:\helpcenter.

4. In this directory, put the DTD, template, r/w rules, etc.

5. Use Structure > Application Definition > Edit Application Definitions to edit your personal copy of structapps.fm.

6. In this file, you will create only your help center application. Since the application definition will probably refer to multiple files in the directory you created in step 3, create a variable called something like HelpCenterDir and set it to the absolute path of the new directory. Specify all filenames in the application as absolute pathnames beginning with the variable. The variable spares you the need to type the path multiple times and also makes it easy to change to a different path.

7. When you are ready to deliver the application to your customers, give them a copy of c:\helpcenter to copy to c:\helpcenter on their own systems and give them a copy of your personal strucapps.fm to copy to their own %appdata% directories.

Let me know if this approach is feasible.

     --Lynne

[Trevor-Nicholls]

Hi Lynne

Yes, you've understood the requirement.

Having gone through this exercise, which I must say was very instructive, I am thinking it might be better to accept what I've got; as I see it this is inferior to the perfect world in only two ways: a new user needs to make a one-time edit to maker.ini, and they can't create a brand New XML document from the Frame shortcuts.

I can live with an edit to maker.ini because all our users have to change a couple of other settings in that file anyway (eg the parameter which strips out all white space). And in practice users can/will open an already-available skeleton XML document when they want to create a new chapter or section. I only noticed the problem with 'New' document because I was trying to write a novice startup guide for our users - and when I discovered that New didn't work as it did for other applications I thought it was important to identify exactly why this was. Now I know, and I've found out a few other useful things too. I expect anyone else following these recent threads will have benefited as well.

I have every confidence that the alternative you outlined above would work if I tried it, and I hope you don't mind if I leave it untried just at the moment,

cheers

T

[Lynne A. Price]

Trevor,

   No need for you to change a file organization that works for you. What's important is that you have something that works for your users and that you understand why the last few changes were needed.

    --Lynne