$('#audioSource') would always return an empty search, because this code was executing as soon as index.html loaded, and the #audioSource element only exists in book.html. We were able to delete pretty much all of this code, and moved the event handler into our book.html pagecreate handlerFinn also caught a bug that I didn't notice yesterday. I always use the search 'abc' in our search bar, which gives just one result—a book on vegetable gardening or something. However, when Finn searched just 'a', a bunch more books were shown, and some of them were displaying with incorrect formatting. He said that the title and description fields of Librivox's book json sometimes contained HTML tags, which were being added to our code.
In order to strip these out, I converted those fields to html using jQuery's
#parseHTML method, and then getting the text of the resulting object (code example). I feel like there's probably a more succinct way to do this, though. This method also seems quite innefficient. #parseHTML for some reason does not return a jQuery object, so we must $() that, then call #text() on it. If there is, in fact, no better way to do this, the code should at the very least be pulled out into its own method, since we are going to need this functionality quite a bit.We also added a position property to the
Chapter object, and have it updating each time the audio player fires a 'timeupdate' event. The current method we're using for this involves using jQuery to select the audio element, then getting the time property. This method fires incredibly fast, and having to do a jQuery element selection each time is inefficient, since I'm sure the event object already contains the current audio position.We also have a bug where the search function stops working after the first search, which definitely needs to be fixed. I think I know why this is happening, but I didn't get a chance to test it out. More on that tomorrow...
I would direct your question about parsing HTML to Kumar.
ReplyDelete