After spending the day figuring out how to generate an Excel file using the Apache POI library I was informed that I actually needed to generate a comma separated format file ( .csv ). Not wanting to waste any of the code or logic that I had written to build the Excel file I looked for a CSV library and I found the apache.commons.csv library.

This library is very simple to implement, once the jar file is added to your XPage application you just need to create a CSVPrinter object and then add all the values that you need to it. The quickest way to do this is create an xAgent style XPage with the code to create the CSV file in the beforePageLoads event.

Here is a simple example of the code required that will loop thru all the documents in a view and export a couple of fields to the CSV file and then send it all to the browser. Note this is just an example, production code would be full of error trapping etc.

// Load the java packages
importPackage(java.io);
importPackage(org.apache.commons.csv);

// generate CSVPrinter Object
var csvBAOS:ByteArrayOutputStream = new ByteArrayOutputStream();
var csvWriter:OutputStreamWriter = new OutputStreamWriter(csvBAOS);
var csvPrinter:CSVPrinter = new CSVPrinter(csvWriter,CSVFormat.DEFAULT);

// Add the header row
csvPrinter.print("EmployeeID");
csvPrinter.print("Lastname");
csvPrinter.print("Firstname");
csvPrinter.println();

// add each exported document
var exportView:NotesView = database.getView("vw_export");

if (exportView.getEntryCount() != 0){
	var exportDoc:NotesDocument = exportView.getFirstDocument();

	while (exportDoc != null){
		var nextExportDoc:NotesDocument = exportView.getNextDocument(exportDoc);

		csvPrinter.print(exportDoc.getItemValueString("employeeID"));
		csvPrinter.print(exportDoc.getItemValueString("lastName"));
		csvPrinter.print(exportDoc.getItemValueString("firstName"));
		csvPrinter.println();

		exportDoc.recycle();
		var exportDoc:NotesDocument = nextExportDoc;
	}
}

csvPrinter.flush();

// Open the servlet Response
var con = facesContext.getExternalContext();
var response:com.ibm.xsp.webapp.XspHttpServletResponse = con.getResponse();

//setting response headers for browser to recognize data
response.setContentType("text/csv");
response.setHeader("Cache-Control", "no-cache");
response.setDateHeader("Expires", -1);
response.setContentLength(csvBAOS.size());
response.setHeader( "Content-Disposition", "attachment; filename="export.csv"" );

// get a handle on the actual output stream and write the Workbook
var servletOutputStream = response.getOutputStream();
csvBAOS.writeTo(servletOutputStream);
servletOutputStream.flush();
servletOutputStream.close();

// Close the renderer and return the document to the browser
facesContext.responseComplete();
}

Rather then writing directly to the response OutputStream I setup a ByteArrayOutputStream in memory and then, because the CSVPrinter requires an appendable outputstream I create an OutputStreamWriter from it and then setup the CSVPrinter to write to that.

Printing a value is as simple as using the CSVPrinter.print(string) method, each time you call this it adds a new value. When you get to the end of the line you need to use a CSVPrinter.println() to add the newline character and then you finish the file it is a good idea to call the CSVPrinter.flush() method to make sure everything is flushed out into the OutputStreamWriter. Then I send the ByteArrayOutputStream to the response OutputStream which is what sends it down to the browser to be saved.

Very easy to use and another great example of how you can use a prebuilt library to extend the functionality of XPages.

Ok, so I pointed out a couple of things to the developers full applications based on the entries to the OpenNTF Development Contest that I judged, now it is time for the developers of the controls.

Make use of the OpenNTF Import/Export Plugin.
There is a great project on OpenNTF that allows you to generate a zip file containing your nsf/ntf along with the license files and a special importlist.xml file that specifies exactly which design elements make up your control. Once this is uploaded to OpenNTF other users can use the same plugin to copy those exact design elements to their application, this will make your control much more reusable.

Create A NameSpace for your design elements
Decided on a prefix for all your design elements that make up the control so that when they are copied into another application there is a much lower chance that they will clash with any other existing design elements. For example I might name a graphic as qtzar_alerts_accept.png rather then accept.png so I know I don’t have to worry about another control that also uses accept.png. The developer using your control will thank you as they won’t have to make any changes to the code to avoid a clash.

Is your control more suited for an Extension Library
If you have developed a fairly complex control that has lots of options and external graphic resources etc. then you should take a look at the Starter XSP Kit project on OpenNTF and learn how to convert your control into an Extension Library. Now that OSGi plugins can be easily deployed to the server via an UpdateSite NSF the admin has no excuse for not deploying the library and by putting your control in a library you make it easier for the developer who doesn’t have to worry about copying in all the other required design elements.

Don’t require server file system changes
A couple of the controls that I judged required that I make changes to the file system on the Domino server, This included changing the java security policy file and in some cases also required adding additional file to the CKEditor system. As an admin I’m going to need a very good reason to change/add files at the file system level and mainly because if I do a server upgrade some of these files may be deleted or reverted back making my upgrade process longer then 5 minutes. For a single control this reduces the reusability significantly.

I’m sure there are a few more, if you have suggestions then please feel free to leave them in the comments.