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

I've been corresponding with a customer recently about their attempt to create a view with way, way too many columns. The purpose of this view is to export data into a CSV file so it can be opened in a spreadsheet. The customer claims this is common -- do you folks agree? If so, I have a new crusade.  :-)

The problem with such a view is that it's huge and causes lots of work for the server, so it's dragging down performance. (Especially if, as in this case, the developer adds a re-sort, ascending and descending, on every column. Oops). My take on this is:

  • You don't need a view to do an export -- a script can do it just fine, and the script costs nothing when not in use.
  • CSV is a poor style of output anyway, because it has none of the nice things already in it that spreadsheet users want, like non-scrolling columns, formatting, totals, pivot tables, macros, etcetera. Obviously you can add those things post-export, or have another spreadsheet with that stuff on it and copy/paste the data, but that's extra work. Wouldn't it be nicer for the users if the data were automatically added into a professionally designed template spreadsheet specific to their task?
  • The user has to go to the export view to do the export -- they can't just do it from anywhere -- and manually select the documents to export from that view.  This ignores the fact that users will typically want to export not a random set of documents, but a group of documents defined by parameters -- all documents for department A in a specified range of dates, for instance -- and it's not straightforward to make such a selection in a view of this type.  Full-text search can locate documents based on such criteria -- but the size of the result set is limited.  Better to have an export dialog that's specific to the task, where they can select the department or whatever, and the desired documents can be located by key searches in a view. And maybe also allow export of selected documents, all documents, or everything in a highlighted category -- just in case.
So the goal is to have the simplest possible way for the user to specify what they want to export, and export it into a spreadsheet that has all the controls they want already in it.  Of course, you don't want to use a program to add all these features; you have someone who knows what they're doing create the power-user spreadsheet manually, and then attach a copy, sans actual data, into a configuration document in your application.  When the user requests an export, you detach the template, then use OLE automation or another API to plug in the data and adjust the size of a range that contains the data.

Since this is a performance topic and I'm presenting about design for performance at Lotusphere, this gives me the perfect excuse to go ahead and write a general-purpose exporter of this type. The configuration document will contain not only the file attachment, but the list of field names/datatypes/formatting strings, column headings (optional), range name, and so forth.

I've got it mostly working and will post it here when I'm done. (UPDATE: see entry dated 1/22/09 for download)

Andre Guirard | 23 December 2008 05:50:00 PM ET | Home, Plymouth, MN, USA | Comments (23)

Search this blog 

Disclaimer 

    About IBM Privacy Contact