XPages DataModels and Exporting to Excel

Chris Connor  May 4 2012 02:44:41 AM

Been doing a lot of work in XPages around Exporting - so naturally built a Java Class to run as a managed bean to do this. It extends the widely documented concept of SSJS Agents in that a button redirects to a page which renders the content as Excel or whatever.

So I thought - let the Excel class have different methods to do different things such as Export a view, a document collection and even the data used in a repeat control (essentially what is on screen). Package it up as an OSGI plugin and it can work for any app - sounds great.

However, the main problem that I am having with this centres around the repeat control export concept which is tied to a dataModel object. Consider the following piece of Java Code.

        public DataModel getRepeatModel(String repeatid) {
                this.repeat = (XspDataIterator) JSFUtil.findComponent(repeatid);
                this.datamodel = this.repeat.getDataModel();
                System.out.println("Repeat rows is "+this.repeat.getRows());
                System.out.println("Data Model Row Count on initial get is = "+this.datamodel.getRowCount());
                return this.datamodel;
        }


Frstly the repeat.getRows() returns 30 = which is to be expected as that is the number of rows that we specifiy in the repeat control. Thats fine ... but....

It seems the dataModel.getRowCount returns 246 documents - even although there are 500+ there. I believe (not confirmed -Wei mentioned this in my blog a while back a while ago that he was having a similar issue) that there is some sort of buffering going on - this could be stopping the processing past this number. Is there a way around this? Is there a better way?

The javax.faces.model.DataModel class is a standard JSF class with methods for things like getRowData() and setRowIndex() which allow you to traverse the structure and seem ideal for this sort of task. Of course if it IS buffering then I am sort of stuck and its workaround time...

One simple idea to get around this could be to to pass in the exact same Full Text Search String that is present for the repeat control. Then I would write a method that runs a second full text search and then process that data. I did something similar a while ago for XDesk on OpenNTF  with its excel export (as we are basically doing a double hit - one to display the data in the repeat from and then again another to export it). It is a full text search so performs well though....but not "optimal" - hate the idea of doing a double hit.

Any ideas on the dataModel class or a different approach would be welcome!

Sure an efficient approach that runs as an OSGI plugin to be shared over all your apps would benefit everyone!
Tweet

• Comments [3]