InfoPath Dev

I have a solution that is partially based on Matt's blog post below

Allow Offline Use of a SharePoint List by Caching Locally

 However when pushing large nodelists into a local DOM  (over 100 entries or so) this can have very bad performance, sometimes mine even hangs.  Therefore, I want to do this operation in parts as the user requires more info.  Somewhat of a pagination function.  So... where Matt does the following

    while( (nSharedItem = nlSharedItems.nextNode() ) != null )
    {
        // Create a new row from the sample
        var nNewLocalCacheRow = nSampleProductNode.cloneNode(true);

        // Set the values
        nNewLocalCacheRow.selectSingleNode( "@ID" ).text = nSharedItem.selectSingleNode( "@ID" ).text;
        nNewLocalCacheRow.selectSingleNode( "@Name" ).text = nSharedItem.selectSingleNode( "@Name" ).text;
        nNewLocalCacheRow.selectSingleNode( "@Description" ).text = nSharedItem.selectSingleNode( "@Description" ).text;

        // Append to to our local cached list
        oLocalDom.selectSingleNode( "/CachedList/Products" ).appendChild( nNewLocalCacheRow );

I just want to do it by 20, or 30 or some lower number.  so my goal is basically to  get the first 20 nodes throw them into the cached DOM, then do a .removeAll() and throw the next 20 or 30 in, rinse, repeat until null is returned indicating the end of the list.  Now I am no XML parsing guru.  I have searched around for about 2 hours trying to find some code like this.  I assume it would use the item() method, but maybe it wouldn't have to since once you have the remote DOM you can loop through it like an array.  My plan for the counter is to have an external two variables that start a 0 and my increment with each iteration.  So x= 0 y = 20.  On each loop x = y; y= y+20. Please help me out if you can.

-Justin 

Hi Justin,

 I don't think you're problem is actually in adding the nodes to the XML, but displaying them in the view.

Do this experiment:  Delete the repeating table from the view and run your code again.

To remedy this, you can use some visual tweaks to make sure InfoPath is only displaying a few rows at a time.  20 or 30 like you mentioned is a great number.  For some more advice, try searching around this site or others for something like "visual tweaks" "increase performance".

 Hope this helps!

 I will check that out.  I have an ugly solution I have come up with myself in the meantime.  I agree from the way it hangs it is definitely the rendering.  By the way do you know how to do what I was suggesting anyway?  Is there a way to parse through a nodelist by the index value?  I am going to post my ugly solution after this post , I am going to look for what you said now.  Thanks for the reply.  If I find something I will post as a reply.

-Justin 

In addition to not showing them all at once, you can speed up the operation considerably by doing most of the work outside of the primary data source and only doing one add operation to the main source.

It will look something like this (in C#):

--------------------------------------------

IXMLDOMNode parent = oLocalDom.selectSingleNode("/CachedList/Products");

IXMLDOMNode workParent = parent.cloneNode(true);

/* ... Do work.  Append to workParent... */

parent.parentNode.replaceChild(workParent,parent);

 ----------------------------------------

That sped things up considerably for me.

I also did a paging type thing you are suggesting.  I inserted the first page and started a seperate thread to add the rest of the data in the background.  But that takes quite a bit of fiddling to get working.

As for parsing through the nodelist by index value.  You could always save the nSharedItem as a global variable and continue on from where you last stoped.  If you don't want to do that you can use position() in XPATH and IXMLDOMNode.nextSibling.

So to get the 11th item you would use:

child = parent.selectSingleNode("child[10]");

and to get the next item in the list:

child = child.nextSibling;

Good idea DJay! Using the secondary DOM will make it much faster.