File Access and Multiuser Configuration API

recommends that you always use the File Access and Multiuser Configuration API to access the file system through C-level extensions. For files other than configuration files, the functions access the specified file or folder.

MX supports multiple-user configurations for the multiple-user operating systems of Windows XP, Windows 2000, Windows NT, and Mac OS X.

Typically, you install MX in a restricted folder such as C:\Program Folders in Windows. As a result, only users with Administrator privileges can make changes in the MX configuration folder. To enable users on multiple-user operating systems to create and maintain individual configurations, MX creates a separate configuration folder for each user. Any time MX or a JavaScript extension writes to the configuration folder, MX automatically writes to the user configuration folder instead. In this way, MX lets each user customize the MX configuration settings without disturbing the customized configurations of other users.

MX creates the user configuration folder in a location where the user has full read and write access. The following table shows the specific location of the user configuration folder for each of the supported platforms:

Platform User Configuration Folder

Macintosh OS X	Mac HD:Users: username :Library:Application Support:: ¬ MX:Configuration
Windows 2000, Windows XP	C:\Documents and Settings\ username \Application Data\\ ¬ MX\Configuration
Windows NT	C:\WinNT\profiles\ username \Application Data\\ ¬ MX\Configuration

There are many cases where JavaScript extensions open files and write to the configuration folder. JavaScript extensions can access the file system by using DWFile, MMNotes, or passing a URL to dw.getDocumentDOM() . When an extension accesses the file system in a configuration folder, it generally uses dw.getConfigurationPath() and adds the filename, or it gets the path by accessing the dom.URL of an open document and adding the filename. An extension can also get the path by accessing the dom.URL and stripping the filename. The dw.getConfigurationPath() function and the dom.URL always return a URL in the MX configuration folder, even if the document is located in the user configuration folder.

Any time a JavaScript extension opens a file in the MX configuration folder MX traps the access and checks the user configuration folder first. If a JavaScript extension saves data to disk in the MX configuration folder through DWFile or MMNotes, MX intercepts the call and redirects it to the user configuration folder.

For example, in Windows 2000 or Windows XP, if the user asks for " file:///C|/Program Files// MX/Configuration/Objects/Common/Table.htm ", MX first looks to see if there is a file called file:///C|/Documents and Settings/username// MX/Configuration/Objects/Common/Table.htm and, if it exists, uses it instead.

C-level extensions, or shared libraries, must use the File Access and Multiuser Configuration API to read and write to the configuration folder. Using the File Access and Multiuser Configuration API lets read and write to the user configuration folder and ensures that the file operations do not fail due to insufficient access privileges. If your C-level extension accesses files in the configuration folder that were created through JavaScript with DWFile, MMNotes, or DOM manipulations, it is essential that you use the File Access and Multiuser Configuration API because these files might be located in the user configuration folder.

Note: Most JavaScript extensions will not need to be changed to write to the user Configuration folder. Only C shared libraries that write to the Configuration folder need to be updated to use the File Access and Multiuser Configuration API functions.

When you delete a file from Configuration folder, MX adds an entry to a mask file to indicate which files in the Configuration folder should not appear in the user interface. A masked file or folder will appear not to exist to although it might physically exist in the folder.

For example, if you used the trash can in the Snippets panel to delete a Snippets folder called javascript and a file called onepixelborder.csn , MX writes a file in the user configuration folder called mm_deleted_files.xml , which looks like the following example:

As MX populates the Snippets panel, it reads all the files in the user's Configuration/Snippets folder and all the files in the MX Configuration/Snippets folder, except the Configuration/Snippets/javascript folder and the Configuration/Snippets/html/onepixelborder.csn file, and adds the resulting list of files to the Snippets panel list.

If a C-level extension calls the MM_ConfigFileExists() function for the URL " file:///c|Program Files// MX/Configuration/Snippets/javascript/onepixelborder.csn ", it returns false . Likewise, if a JavaScript extension tries to call dw.getDocumentDom("file:///c|Program Files// MX/Configuration/Snippets/javascript/onepixelborder.csn") , it returns Null .

You can modify the mm_deleted_files.xml file to prevent from showing files in the user interface, such as objects, canned content in the new dialog, and so on. You can call MM_DeleteConfigfile() to add file pathnames to mm_deleted_files.xml.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117

India web developer website development India