IBM®
Skip to main content
    Country/region select      Terms of use
 
 
   
     Home      Products      Services & solutions      Support & downloads      My account     

developerWorks  >  Lotus  >  Forums & community  >  Best Practice Makes Perfect

Best Practice Makes Perfect

A collaboration with Domino developers about how to do it and how to get it right in Domino

Nathan is right, "/" seems to work as a path delimiter on all operating systems that the Notes client runs on (current versions). Also, nobody seems to care if you have two consecutive path delimiters. So the PathDelimiter function is unnecessary; we can just write:

m_filepath = GetNotesTempDirectory() & "/" &  unik(0) & "." & suffix

I agree this should be a property of NotesSession, as should the OS temp directory path. I will propose this as a feature request.

Meanwhile, Brian Miller asks how we might get the Notes temp directory on AIX. Refer to this page on openntf.org which shows how to declare C API functions for several different operating systems.

There does not, however, seem to be an argument to Environ for each operating system that will return the OS temp directory for that OS. Here's a way that I believe will work.

Function GetSystemTempFolder As String
   Dim session As New NotesSession
   Select Case session.Platform
   Case "Macintosh", "Linux", "UNIX"
      GetSystemTempFolder = "/tmp"
   Case "Windows/32"
      GetSystemTempFolder = Environ("TEMP")
   Case Else
      Error ERR_UNSUPPORTED_PLATFORM, "GetSystemTempFolder: Unsupported platform '" & session.Platform & "'."
   End Select
End Function

For client work in general, it doesn't really matter whether you use the OS temp folder or the Notes temp folder because you have both folders to yourself. When you write code to run on a server, however, it's better to use the Notes folder. If there are multiple Domino partitions running on the server, each partition has its own Notes temp directory, but there's a common OS temp directory. Using the Notes temp directory gives less chance of filename conflicts. There's even less chance of a problem if you use a file name from @Unique as I did in my example, or create a folder with a name from the @Unique function, and put your files in there. Since Notes puts lots of files right in the Notes temp directory with names not chosen at random, it makes sense to avoid doing the same. For instance, if you want to temporarily detach a file from a document, rename it, and import it into a new attachment (as a way of renaming the attachment), it's best to do this in a folder where you're unlikely to encounter any files created by other code. Whatever you do, do not write temporary files into the default directory, which in most cases is the Notes program directory. This can result in the overwriting of important files that are part of your Notes client or server, involving you in difficult conversations with the administration and security staffs of your company.

Kerr wants to know what all this is in aid of, where I'm getting  base64 data, why I'm bothering to decode it, and what I do with it after. Kerr is nosy, but I guess I'm willing to say. One of the features of the Developer's toolkit I blogged about recently, is a selection to display the "raw" XML of a Composite Application design element or a Wiring Properties design element. So the output looks something like this (use right-click, View Image to see it full size).

Wiring properties XML dumpTo get the XML, I export the Wiring Properties design element into DXL, using a special little trick to make the exporter treat it as a file resource so that it converts the binary CD records of the $Filedata item back to the original file contents, which are base64 encoded as a text node inside a "filedata" element. I then have to decode the base64 data, which I can do using the NotesMimeEntity class. (It's possible to directly decode the CD records of the binary $FILEDATA item back into the original file data using LotusScript, but messy. Very messy.)

Of course, you could do this from the Designer menus by exporting the WSDL files to disk and then opening the files in your favorite XML editor, but this is a two-click operation to see the XML for all your Wiring Properties instantly.

BTW, I'm aware that viewing raw XML is not everybody's cup of tea, so I have an another tool for Wiring Properties that parses and summarizes the data, as shown below. For this operation, I don't need a stream with any particular character set, because our XML parsers don't pay any attention to the character set specification in the NotesStream anyway -- they just look at the bytes in the buffer, and figure out the character set from that, in the usual way of XML parsers everywhere. So the TempFileStream class is not needed in that case.

Report of Wiring Properties

Andre Guirard | 3 October 2007 03:35:40 PM ET | Plymouth, MN, USA | Comments (21)

Search this blog 

Disclaimer 

    About IBM Privacy Contact