nsIFileOutputStream with a relative path

[Steff81]

Hi,

i`m writing a addon for lightning.
a addon for automatic exports.
many user asked me for a export to a relative path.

currently i am using following code (from the original lightning code)

< var outputStream = Components.classes["@mozilla.org/network/file-
output-stream;1"].createInstance
(Components.interfaces.nsIFileOutputStream);
< try{
< outputStream.init(pathForExport, MODE_WRONLY | MODE_CREATE |
MODE_TRUNCATE, 0664, 0);
< exporter.exportToStream(outputStream, calendarEventArray.length,
calendarEventArray, null);
< outputStream.close();

but there is no chance to change from a absolute path to a relative
path.
i didn't find anything on mdc or some other pages.
can anybody help me?

thanks in advance
regards
steff

[Georg Maaß]

Steff81 wrote:
> but there is no chance to change from a absolute path to a relative
> path.

each relative path must be relative to a root. You may prepend the
absolute path of that root to your relative path to get the necessary
absolute path.

A relative path in XulRunner usually is relative to the directory
holding the chrome.manifest. In many cases this is the parent.parent
directory of chrome://APP/content/

Taking the path of that directory might help to calculate the absolute path.

[Steff81]

hi....

thanks for your reply.
sorry, but can you give an example?

I'm using .....

> outputStream.init(pathForExport, MODE_WRONLY | MODE_CREATE | MODE_TRUNCATE, 0664, 0);
> exporter.exportToStream(outputStream, calendarEventArray.length,calendarEventArray, null);

"pathForExport" needs to be a absolute path.

> var pathForExport = Components.classes["@mozilla.org/file/local;1"].createInstance(Components.interfaces.nsILocalFile);
pathForExport.initWithPath(dirForExport);

"dirForExport" is already an absolute path like (D:\Kalender\ICS.
no it would be nice if i could use for example
pathForExport.initWithRelativePath(relativePath,
startingPointOfRelativePath);

[Georg Maaß]

Create a nsILocalFile instance for the directory your relative path
values are related to. I use chrome URLs for this purpose to specify
this directory. I.e. the url chrome://myApp/content/ is an abbreviation
for the file myApp.xul in the content directory of your application. To
get a nsILocalFile from a chrome URL you first must convert the chrome
URL into a file URL.

var chromeURL = 'chrome://myApp/content/';
// convert the chrome URL into a file URL
var crs =
Components.classes['@mozilla.org/chrome/chrome-registry;1'].getService(Components.interfaces.nsIChromeRegistry);
var ios =
Components.classes['@mozilla.org/network/io-service;1'].getService(Components.interfaces.nsIIOService);
var nsIURI = ios.newURI(decodeURI(chromeURL), 'UTF-8', null);
var fileURL = crs.convertChromeURL(nsIURI).spec;

// get the nsILocalFile for the file
var h =
ios.getProtocolHandler(Components.interfaces.nsIFileProtocolHandler);
var nsIFile = h.getFileFromURLSpec(fileURL);

Now you have a nsILocalFile for a known URL. This has a path property
containing the absolute path of this known item. It also has a parent
property pointing to the nsILocalFile of the parent directory, which is
in this sample the content directory of your application. The path
property does not end with a slash.

Assuming your files with relative path are siblings in the content
directory of your application, you simply calculate the absolute path
for any of your files by taking nsIFile.parent.path + '/' as prefix of
your relative path. On windows you probably need '\' instead of '/'.
Which directory level separator is needed you also can calculate by
nsIFile.paths.charAt(nsIFile.parent.path.length)

I recommend to do everything with constant path values using chrome
URLs, because this gives you the possibility to redirect by modifying
just the chrome.manifest of your application.

In my application there are dozens of chrome directories specified in
the chrome manifest. When I update anything, it is stored in a new place
and the path in the chrome.manifest is relocated to the new location.
After restarting the application is updated to the new implementation.
Switching back to old implementation is just relocating the path in
chrome.manifest back to old values. This is very similar to what Apple
does with its Frameworks, that are implemenented in multiple versions
parallel, but only one is the current implementation, which is
identified by symbolic link called current. Instead of symbolic links
that are not compatible with zip files, I use the chrome.manifest to
say, which directory holds the current version. Using the
chrome.manifest for this also has an other advantage: it is platform
independent toolkit built in technology. Symbolic links are platform
dependent.

[Neil]

Georg Maa� wrote:

> Assuming your files with relative path are siblings in the content
> directory of your application, you simply calculate the absolute path
> for any of your files by taking nsIFile.parent.path + '/' as prefix of
> your relative path. On windows you probably need '\' instead of '/'.

nsIFile actually supplies an Append function that automatically uses the
correct separator.

--
Warning: May contain traces of nuts.