multiselect
multiselect copied to clipboard
michael
Slow with large lists
Hi, The function is great, looks professional and ease of use. Problem is I can see that it takes up a very long time to generate the mark with list over 500+ items. Is it possible that I can produce the html mark up for the html page in advance and the multiselect function doesn't need to produce the it, but the javascript functions still work. My idea would be to use PHP script to create the markup list to save the javascript from doing it. Cheers Kaz
Hi, pls see Yanick's fork at http://github.com/yanickrochon/multiselect/. He did a lot of improvements, and also implemented remote (ajax) list population. I'm planning to merge back most of his changes to my repo as soon as I can get some time together.
Cheers, Michael
Thanks Mike! I had to reopen my gedit with that file again this week, as I need to replace the very first version of that widget with search capabilities with a more recent one. I did a rewrite of the droppable/sortable, but it's not quite functioning completely when both lists are sortables, but I think I'm on to something there. Anyway, using the it as it is, works farily well. ...moving on....
To the the op (whaz), you cannot save a markup for this widget as it relies on dynamically bound events and other data cache. For an extensive list, that why I had to add the remote call feature because I was on the same track as you. The script is farily easy to use, and definitly customizable. Good luck with that!
yes, this is an issue that has been talked many times before. The markup and the number of events to bind to each item is too excessive for lists with extensive number of items. This is why a "Search" was implemented to populate the list will smaller chunk of items per search. I personally calculated that a list with 500 item did fairly well in most browsers (especially IE, the slowest of them all)
The initial design did not take in consideration lists greater than a few hundreds. Perhaps, if someone is interested, a better implementation would be to use a data model as backend and display only the visible items inside the viewport (like SlickGrid does) ... but this would require rewriting much of the code, and would probably be for a next major release of the widget... anyone up to the challenge? :)
I hear yah, unfortunately my jquery experience is a little lacking to take up the project. Time is also not something on my side right now. I wonder how hard it would be to tie in to the scroll bar and implement some type of scroll based paging mechanism.
Hello, link provided above doesn't work anymore,
are there any plans for this project or has it been stopped?
Wouldn't it be far faster if it used composing HTML+innerHTML and jQuery.delegate? I haven't profiled it though.
I did some profiling in Chrome and found that if I removed the hide() in _getOptionNode and the show() in _populateLists things were much faster, without any obvious impact on the widget. Let me know if I've done something bad! :)
