Re: [Xsltforms-support] different behaviour for IE and Firefox - position() inside repeat.

[Stephen C. <Ste...@ut...>]

Fantastic Alain, Thanks!

See comments below


From: COUTHURES Alain [mailto:ala...@ag...]
Sent: Wednesday, 5 January 2011 7:23 PM
To: Stephen Cameron
Cc: xsl...@li...
Subject: Re: [Xsltforms-support] different behaviour for IE and Firefox - position() inside repeat.

Hello Steve,


Specifically the position() XPath function does not work inside an xf:repeat in FF v3.6 but does work in IE  v8.0, thus you see an incrementing row-number in the first column of the table in the later but not in the former.
In fact, IE is the wrong one! You should used xf:output/@value instead of xf:output/@ref for rendering XPath expressions which are not also node sets. There is no error message about that but there should be one.

Oh, is this saying render the node value, as opposed to render the value of the first node in the nodeset?

Also, as you can see there is still a major difference in the relative performance between IE and FF in this 'paging' table demo using dataisland branch. Viewing the F1 Xpath evaluation times its clear that  the Xpath for the repeat 'page' nodeset is by far the longest time (>2500 ms in IE). I tried rewriting this XPath to see if I could improve this time but without any success.

Its pretty clear why this should be expensive as its actually testing each of the 1000 gml:featureMember nodes to see if they match the predicate, as follows:

instance('airport')/gml:featureMember[position()>=instance('grid1')/pos and position()<instance('grid1')/pos+instance('grid1')/stride]/*

However, changing this to the following (which is not quite correct logically but potentially better) doesn't improve the time at all:

instance('airport')/gml:featureMember[position()=instance('grid1')/pos]/following-sibling::*[position()<=instance('grid1')/stride]/*

The logically correct path would be:

instance('airport')/gml:featureMember[position()=instance('grid1')/pos]/self::* | following-sibling::*[position()<instance('grid1')/stride]/*

I tried looking at the generated XPath 'XXXExpr' functions, to understand why this might be the case, but so far without any insights.
I'm now designing a commercial version of XSLTForms for performance issues. This implies as many changes such as the ones done for the dataisland branch, first, but will allow to change the general behavior of XSLTForms consisting now in looking at everything if there is something to be done or not.
Unfortunate but if that's the only way forward for you then so be it.  Possibly worth going along that path for a while to see what happens, maybe if some people thing no more will come for you for free they will put their hands in their pocket to help continue it as fully open-source. Personally I think the current XSLTForms version is capable of making money for people.

XPath 2.0 partial support can help: in this test case, the "to" operator could be used.
I can't see how or find an example, surely not  "node[x to y ]"?
Maybe something like "node[member-of-set(position(),x to y)]"?

There are also possibilities in adding useful extensions. You can already try this experimental extension: add xf:instance/@readonly="true" to each instance with a static content and it will not be validated at loading time. For your test case, the loading time is divided by 2!
WOW! This test really rocks now in FF and shows the client-side XForms engine advantage in full glory.

Not only loading time but moving between pages is faster as well, in fact as fast as what I'd hoped for, marvelous :)


Unfortunately, a commercial version requires also to work on obfuscating XSLT+JS and on restricting use on a registered domain name.



A lot of work implies a lot of time and any kind of support is welcome!

Best wishes for 2011

-Alain