Question

Project:formsPlayer
Version:1.6.1030-dev
Component:User interface
Category:support
Priority:normal
Assigned:abb
Status:new
Description

Hello Paul,

One of the members of our team has the below question (related to autocomplete feature which he has implemented. Could you please provide your inputs on this. I shall post this on the issue site too. But the war file is part of this mail which you can use to see the effects..

Regards
Nirmal

Using XForms, I've put together a declarative-based (there's a bit of javascript) auto-suggest mechanism. It seems to work correctly but the performance prohibits me from releasing it. The demo contains 4 sample auto-suggest interaction points. The button (trigger) to the right of each input box selects all entries (mimics a select box). The input box will process the user-typed auto-suggest input. These lists are small, around 20 entries.

On formsplayer 1.4.3, it takes 2 seconds to see an entire list

On formsplayer 1.6, it takes 9 seconds to see an entire list

On Mozilla XForms 0.8.5, it takes seemingly no time to see an entire list

The culprit seems to be a bit of xpath - the one that selects the list to show based on typed-in input, for example:

xf:bind
id="xfs_4_list"
nodeset="instance('teamList')//nfc_teams/football_team/@club_name[starts-with(.,instance('xfs_4_input_tmp')/root)]"

So the first instance is the entire list, the 2nd instance is the input from the auto-suggest input field. If the button is clicked the 2nd instance above is cleared causing all entries in the first instance to be selected. The xpath is just selecting those entries in the master list that start with that typed-in the input box.

Is the xpath above not reasonable for performance oriented use by formsplayer? If not, why is the performance so good in the Mozilla player?

The attached file contains the formsplayer version (index.html) and the Mozilla version (findex.xhtml) for reference

Updates

#1 submitted by Paul Butcher on Wed, 2008-07-16 09:46

For performance reasons, I would advise against using "//" in XPath expressions. Particularly when operating on large instances, as it means that the right-hand part is evaluated in the context of every descendant node of that returned by the left-hand part. The evaluation of XPath expressions is something that formsPlayer outsources to MSXML, so I can't really say what makes its performance over such expressions poorer than that of Mozilla.