Re: [Xsltforms-support] Improving XSLTForms performance in IE

[COUTHURES A. <ala...@ag...>]

Hi Steve
> I recently had feed-back from some users and the main issue was slow 
> form loading in IE.
>   
Real world feed-backs are always interesting. There are two situations 
where it can be slow with IE: at form loading and at form refreshing.
> I am wondering if there may be ways to get around this. I think that I 
> am mainly having problems due to large XML files being included as 
> external xform instances, that are then parsed into 'XDocument' 
> javascript objects by XSLTForms.
>   
Maybe external instances should be loaded at the XSLT step. It could 
also be possible to generate all the XNode calls at the XSLT step to 
eliminate both the XSLT serialization and the Javascript parsing!
> I previously asked Alain if these could be natively parsed as 
> DOMDocument objects by the browser and then used as such by XSLTForms. I 
> think that the reason why this could not work is the lack of XPath 
> support in browsers. However, I now wonder if a half-way house solution 
> might work. That is XNodes are wrapper objects for DOMNodes and the 
> XSLTForms Xpath evaluations are actually using the DOMNode name, values 
> (or childNodes) behind the scenes.
>   
DOMNodes are not exactly the same for each browser... and there are 
already some Javascript instructions to handle this.
> So the XDocument.parse() method would, in the case of external 
> instances, build a tree of XNodes each holding a reference to a DOMNode 
> and for each evaluation of such an XNode, the node itself would have to 
> decide if it was purely javascript based or DOMNode based. If this 
> mechanism might possibly work, I'd be happy to have a go at trying it out.
>   
A native Javascript parsing would probably require to add extra 
attributes and methods to obtain an identical structure for each browser.
> I think XSLTforms has a niche only because all browsers do not support 
> the Xforms standard natively. If you are an organisation using Xforms 
> then there is no problem to use a plugin (though I've not tried one), so 
> XSLTforms is filling the opportunity for a cross-browser solution but it 
> hasn't quite got there yet in my view due to the current slowness in IE. 
> Realistically, trying to add more feature support is not a good use of 
> time whilst this problem exists.
>   
XForms as a plug-in sounds to me more or less like an abandoned solution 
today. Server-side solutions seem to be more and more active but 
XSLTForms is apparently the only client-side solution being improved now.

About new features, upload is still on the list.
> Browsers are very fast at parsing XML and also transforming using XSLT, 
> it seems to me that XSLTForms is making good use of the later but 
> ignoring the potential of the former.
>   
Yes, you're right and it would fix some serialization problems. ;-)
> Not using IE is an option perhaps, but you have to ask what is XForms 
> competing against and is the competion working OK in IE?
Are you talking about IE 6 too???
> For me at least 
> the competition is AJAX frameworks that can auto-generate a web-app from 
> a relational database schema and do client-side validation. There are 
> plenty of options in this space and all work well in IE I'd say (we use 
> ZK framework).
>   
XForms is better with XML databases of course.

XSLTForms doesn't have full-time contributors yet but it would deserve 
them...
> My intention is not to put down XSLTforms at all, just to state my 
> concerns about priorities.
>   
Strategy is important and performance might block real-world use if it 
isn't considered enough.

I have to study all this for each recent browser now. Do you have a list 
of browsers to be supported by XSLTForms?

Thanks!

-Alain