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

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

Thanks Alain,

See my comments

COUTHURES Alain wrote:
> 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. ;-)
I don't understand fully the implications of what you are saying above 
but it sounds like there are some possibilities to try that might 
improve things, which is good news. I'll send you something that I did 
before as a test that might be relevant to this discussion. I hope i can 
do some tests on this area soon.

Also, IE 9.0 looks to hold some promise of improved javascript 
performance, so longer term the prospects for XSLTforms with IE seem 
brighter. This is not to say that improvements across all browsers 
aren't desirable and worth exploring.

>> 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???
No IE 6 is too old to worry about, I'd be happy just to consider IE 7 & 
8, I am interested in scientists working in institutions that might have 
a restriction on installing software on PCs, if this means still using 
IE6 then something is badly wrong, larger institutions maybe not so 
easy. I am not interested in forms for use by the general public, these 
usually need coded business logic on the server anyway so you might as 
well use a server-side solution to be able to include that.

>
>> 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...
Agreed, my interest is similar to XML databases, to be able to easily 
set up a XML web-service and interact with it via XForms, that is, with 
very little programming skills and effort. I'd like at some stage soon 
to set up a site to promote this idea and provide example forms to study 
or copy. Also, looking at what the XRX model offers for scientific data 
management and handling as well.

>> 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
>
>


-- 
Regards

Stephen Cameron

Data Programmer
Integrated Marine Observing System  (IMOS)
eMarine Information Infrastructure Project
University of Tasmania, Private Bag 21, Hobart, TAS 7001, Australia

Tel: +61 3 6226 8507
Fax: +61 3 6226 2997
Email: ste...@ut...
URL: http://www.imos.org.au/eMII.html