Sorry about the failure to reply on that Max. I actually was able to
apply a couple fixes but they are not ideal.
What I previously had done was use dynamic datapaths. For example:
<attribute name="tkey" value="MA" type="string" />
<view datapath="${'xmldata:/states/'+parent.tkey+'/contacts/'}">
</view>
In our application the data would refresh itself automatically on timer
and we didn't want to see it flicker every time it refreshed. So, to
pool the data I did this:
<attribute name="tkey" value="MA" type="string" />
<view datapath="${'xmldata:/states/'+parent.tkey+'/contacts/'}">
<datapath pooling="true" />
</view>
It worked in v4.0.16. Doing this also ensured that the constraint for
datapath always pointed to the right parent view. If for example I did this:
<attribute name="tkey" value="MA" type="string" />
<view >
<datapath xpath="${'xmldata:/states/'+parent.parent.tkey+'/contacts/'}"
pooling="true" />
</view>
The xpath constraint would be pointing to the wrong parent view in
certain instances.
To get around this, I added a duplicate attribute 1 level above it and
pointed it a level higher like this:
<attribute name="tkey" value="MA" type="string" />
<view>
<attribute name="tkey" value="MA" type="string" />
<view >
<datapath
xpath="${'xmldata:/states/'+parent.parent.parent.tkey+'/contacts/'}"
pooling="true" />
</view>
</view>
This way, whether or not it matched a single node or multiple nodes, the
constraint was still valid.
I would have preferred to have it work the previous way like in 4.0.16
but I understand the reasoning.
There was also a second issue I found that was quite frustrating. Had a
class that was supposed to have a pooled datapath:
<class name="testClass">
<datapath pooling="true" />
</class>
Then the view that used it would look like this:
<testClass datapath="somedatapath:\somewhere" />
In 4.0.16, doing this would cause only the xpath attribute of the class
to be overwritten. In 4.7.2 and above, doing this causes the whole
datapath element to get overwritten, removing the pooling=true
assignment. The workaround was doing this:
<class name="testClass">
<attribute name="dpath" value="" type="string" />
<handler name="oninit">
if(this.dpath!=null && typeof(this.dpX)!='undefined'
&& this.dpX.xpath==null)
this.dpX.setAttribute('xpath',this.dpath);
</handler>
<datapath name="dpX" pooling="true" />
</class>
<testClass dpath="somedatapath:\somewhere" />
Seems to me that in both of these instances a resolution could be
changing the 'datapath' attribute on 'view' to 'xpath'. Then if xpath is
set it's applied to the datapath.
By the way, in my last example above, I tried every other possibility I
could think of such as adding a datapath element to the testClass view
and even having the xpath attribute determined by constraint. Nothing
worked but what I did above.
Finally, the last thing I'm noticing is that categorized dataset
elements are firing in reverse order when pooled after the first load.
For example, here's the dataset:
<widgets>
<widget index="1" category="red" />
<widget index="2" category="red" />
<widget index="3" category="red" />
<widget index="4" category="blue" />
<widget index="5" category="blue" />
<widget index="6" category="blue" />
<widget index="7" category="blue" />
<widget index="8" category="blue" />
</widgets>
For display, I'd have to rows, one for red and one for blue.
Using a Debug.write statement that output the widget 'position()' and
'last()' items, I was able to determine that when pooling is set to true
the red category would send the ondata event for each widget element
first followed by the blue category on first dataset load but on
subsequent loads the blue category would send the ondata event for each
widget element first followed by the red category. Unfortunately, it is
important in our app that red goes first, blue second (just like they
appear in the dataset).
My workaround will have to use a counter value to determine when all
widgets send ondata so that the sequence isn't interrupted.
As you can see, just a couple of real annoying changes.
Ryan Maslar
