Closed saulposel closed 11 years ago
The indexed class tells the code that this page contains a list that you want the listIndex attached to. listIndex is that class that attached to the div tag that contains listIndex. This prevents multiple listIndices on a page. Check it out in Safari's web inspector.
The logic in line 239 says if any element in the page has a indexed class and the page hasn't already been given a listIndex then add a listIndex. With our mod you could put a listIndex on any page wether or not there was an unordered list on it. Since you're using JS to dynamically create a page I don't think that pageInserted will get fired. You'll have to call initListIndex(<pageID>)
after you've appended the page to the DOM.
Hi,
Noticed something trying to adapt code to work for me.
I have a list that is populated through javascript from a html5 database (local storage). I only want the list to be indexed once it has been populated from the database javascript call.
As such, I removed the "indexed" class from the wrapper div (to prevent a list index being created before the list is populated) and instead manually call initListIndex('page') once the db call completes.
I noticed that this wasn't adding the IDs to the separator divs in the list and did some debugging to see why that was.
It comes down to line 239:
The code to index a single page check that there is an element with class "indexed". As far as I can see, you can only end up working on a single page if you call it manually or on "pageInserted". As "pageInserted" checks if there is a child with ".indexed" (line 284), this check on line 239 seems redundant and results in a manually requested index failing.
It is somewhat likely that I have overlooked something here, but if I haven't, I think logically, line 239 can be changed to the following, which enables manual calling of indexing:
I look forward to hearing your thoughts on this.
Thanks again!!