zotero does not recognize AJAXified results?

narcis

im adding zotero support to our search engine for dutch academic resources by means of an unAPI server.
All works well for the first bunch of search results (you can add them all to zotero in one big sweep) but the resultspage is ajaxified, so getting the next X results doesn't change the html, and thus doesn't trigger the zotero plugin to notice the change.
When you try to add these next results to zotero, you add the results of the first page instead.

How do I tell the plugin that he should re-examine the dom?

dstillman

I don't know the specifics of why this isn't working, but the Zotero translators will often, for example, just take the current URL and make another request based on some query string parameters, so problems like this wouldn't be unusual with dynamically generated results.

If I may ask, though, why use AJAX for a full page of search results? (I recognize that this may be outside of your control.) AJAX is great for some things, including search result drop-downs, but dynamically generating an entire page of search results doesn't seem very user-friendly, since it means there's no real URL and (generally) prevents users from using the Back and Forward buttons. What's the benefit?

(Of course, there are plenty of OPACs (and other webapps) that don't use static URLs, even for individual record pages, and that's just as hostile to users.)

Anyhow, if you want to make this work with the existing design, you might try looking at the unAPI translator and examining Zotero's debug output to see what's going on.

narcis

well, the ajax thing is not really up to me ...

I'm not sure i understand what you're saying. do you mean i have to write a translator as well? the unapi server serves RIS formatted results, so the plugin recognizes them already. surely there is no need to write a translator also?

the zotero plugin queries the unapi server when the page is loaded, but i would like it to requery it when the dom has changed. is there a way to do this?
i noticed the operator plugin has this kind of awareness of changes.
i figure with the increasing popularity of ajax this will be a recurring feature request ...

dstillman

do you mean i have to write a translator as well? the unapi server serves RIS formatted results, so the plugin recognizes them already. surely there is no need to write a translator also?

No, I mean what I said—that you might want to look at the unAPI translator code (in Scaffold, perhaps) and/or the debug output to figure out why it's only returning the first page of results.

Generally there's no persistence of state between the translator detect code and the translator save code. I'm not sure if this is different for unAPI. If it is caching something, it's possible we could retrigger the detect code on unAPI-specific DOM changes.