Fire zotero action on AJAX action?

hjansen · June 12, 2008

I'd like to add a zotero translator for the next release of our library portal (internal testing only at the moment).
I think I have understood how translators work in general but I have a question related to the workflow of our software:
We provide search results as lists. Zotero can iterate over all items in the list when the page is loaded and import every entry, but that might create quite some traffic. Therefore, I'd like Zotero to react only to full record views. Full views, however, are not displayed in separate pages but are incorporated in the list view through AJAX.
What would be the best way to have the Zotero callback functions invoked whenever a new full record is requested by a user and added to the already loaded page?
Should I register an event handler in the DOM of the list view page? Or are there other options?

Thanks for the help
Heiko

PS: Ultimately we'd like to work with RDFa but currently that seems to be not supported by Zotero. And even if it is, we're unsure which metadata set to use (I haven't yet grokked how to use MODS with it's attribute-qualified hierarchical fields together with RDFa). If anyone could point me to a solution using RDFa with complex metadata schemata I'd be very happy!

dstillman · June 12, 2008

I asked the same question on another thread, but why would you use AJAX for full record views? Doesn't that mean no static URL, no bookmarking and no Back/Forward button support (unless you're going well out of your way to reimplement those features)?

Zotero's translator detection (detectWeb) currently triggers on Firefox's pageshow event. It's possible we could update it to re-run detectWeb() when the named anchor changes in the URL (e.g. /results#record1), since that's how you'd produce static URLs in an AJAX app. Other than that, there wouldn't even be a static URL for Zotero to include with the saved record, so I don't think we'd bother to support that.

hjansen · June 13, 2008

To your questions:

a) The system works like this: You get a list of hits and can see the full record of one or more list entries using AJAX. You can navigate through the lists (next X hits, previous X hits) without AJAX and if a user disables JavaScript the full record views (pages) replace the list view.
Incorporating the full view in the list simplifies the navigation for the user.

b) No, there is no static URL to the bibliographic records. We have a metasearch engine. The hit lists (x records from each of y databases - so possibly quite large) are dynamically assembled and only valid within a session (due to - amongst other reasons - our need for authenticating and authorizing the individual user for access to licensed databases).
Apart from that, a majority of the available databases does not provide a mechanism for fetching one specific record again based on a record id. So, no, we cannot produce a static URL. If that is a requirement for Zotero I can stop thinking about a site translator right now and concentrate on extending our support for BibSonomy, RefWorks etc.

To your suggestion: We do not change the anchor in the URL. Would be quite complicated because a user can have more than one full record visible at the same time.

I'd rather suggest that site translators should be enabled to register event handlers on page load (within detectWeb) that can trigger Zotero record detection and the site translators import whenever AJAX functions modify the page.

dstillman · June 13, 2008

OK, thanks for the explanation. A static URL isn't a requirement for Zotero—there are a number of OPACs that Zotero supports that don't provide them—but I think not providing one is a pretty user-hostile practice in general, usually without a particularly good technical reason. But you obviously have a good reason—namely, that you're limited by what the upstream services provide (which kinda proves the point).

What kind of event handler would you need? I could see translators being able to register (in an abstracted way) for a subset of the DOM events (e.g., DOMSubtreeModified, DOMAttrModified, etc.). When an event was triggered, the detectWeb() function for that translator would be called again.

hjansen · June 13, 2008

Regarding the kind of event I'd need: You got me there. I'm familiar with event handlers like "onclick" and the like, but was unaware of the DOM mutation events.

Originally, when I read about the translator workflow I had something in mind like registering an "onclick" handler for the links to full record displays. But that wouldn't have been the most elegant solution since this event (and similar ones like "onsubmit") occur before the actual content we're interested in has been received.

From what I see in the W3C standard, DOMSubtreeModified seems to be the most generic approach.
Restricted to our particular case, however, the ability to register a (number of) "DOMNodeInserted" event(s) might be the best choice, because with that the translator functions could also get information about where the new content was inserted. Therefore they would have no need to traverse the whole DOM over and over again, keeping track of what had already been there and what's new.

If you or someone else would start to implement something like this I'd be happy to provide access to our web application as a testing ground: I cannot - at the moment - provide a public link here, because it's not yet beyond the phase of closed testing.
Unfortunately (well, depending on the point of view) I'll be on holiday for 2 weeks starting from tonight. So please don't be surprised or annoyed if I don't respond to questions immediately - I _will_ answer sooner or later.

--

03.07.08: Being back from my holidays I'm wondering if there's anything I can do to further this kind of development in Zotero?

parod · January 22, 2009

We have a similar application that loads divs containing COinS markup via Ajax after the page is loaded, which we would like Zotero to sense. Is there a recommended way to request Zotero to take another look at the page?

Has there been an further guidance on this topic?

Simon · January 22, 2009

parod, for your case at least, triggering the loading of the divs with DOMContentLoaded event should work. Zotero doesn't check for translators until the onLoad event.

mbklein · February 3, 2009

We have a search page with AJAXified results, and it does provide a persistent URL using a URL hash. Every time new search results are loaded, the hash changes to reflect the new query terms and facets applied. This allows the dynamic results to be bookmarked, and full forward/back browser history navigation is supported.

I added two lines of code to the Zotero codebase and two lines of code to my own browser-side AJAX script to allow the results to be seen and scraped by Zotero, without the massive overhead of having Zotero re-scan every time the DOM changes.

My code tells Zotero to listen for two custom events -- bibdatachanging and bibdatachanged. The former calls Zotero_Browser.contentHide(), and the latter calls Zotero_Browser.contentLoad(). I just fire one manually before I refresh my result div and the other after, and Zotero becomes aware of the new data just fine.

Is this an appropriate place to share my code, or can I email a patch to someone?

hjansen · March 21, 2009

Implementing support for direct exports to BibSonomy or RefWorks was comparatively easy (and we're working on supporting other similar services) but we still would like to offer Zotero support. But there still seems to be no way of making Zotero recognize ajax page changes (adding elements with COinS data) if these are added to the page by user-triggered AJAX functions after the base page has been loaded.
Not even if I manipulate window.location.href by assigning it a new hash anchor text.

Are there any plans for improving this situation? E.g watching for certain DOM events and rescanning the page when they occur? Or is there anything else I can do or am missing?

parod · April 19, 2009

I haven't been successful in triggering Zotero to reexamine an Ajax-changed DOM for COinS. If someone would post or forward complete Javascript, that would be fabulous.

MBKlein, your code example would probably help a lot if you're willing. Just understanding how to set up the environment - what to include - to invoke Zotero_Browser successfully would be very helpful to me.

Sorry to be dense. I haven't done this kind of plugin interaction before.

Thanks very much in advance.

hjansen · April 20, 2009

I'm currently taking evasive maneuvers implementing a custom translator. It works quite well but still needs some polishing before submitting.

Once it is finished and accepted for the translator repository of Zotero I'll consider this case closed on our side.

I'd, however, still suggest that Zotero should be equipped with a means for recognizing / handling AJAX based page manipulations since I believe that usage of this design pattern will continue to rise.

dean-o · February 11, 2010

I wanted to "bump" this.

A site I am working on is heavy AJAX so as users modify the contents of the page Zotero doesn't recognize the updates (we're using COinS). When I say it doesn't recognize the update, I only mean the little yellow folder icon in the address bar -- that doesn't appear or disappear as collectible content appears or disappears from the page.

Oddly enough, if the icon is there on the initial page load, spydering the COinS after the contents of the page is updated, still works. Which is nifty.

So, how about something as simple as letting my JS reveal/hide the little icon? Remember, my JS knows if there is any COinS on the page or not, so it won't get it wrong.

In the mean time, (in case this helps others) I'm hard-coding a dummy COinS into the initial page load - always. So the icon always appears. I add a blank entry twice so the yellow folder appears (vs/ the blue book icon), and leave out metadata so at least Zotero won't add anything:


Thanks!

dstillman · February 12, 2010

So, how about something as simple as letting my JS reveal/hide the little icon?

That's a privacy issue and also a bit of an ideological one. Sites shouldn't be able to tell when a user has Zotero installed—and they shouldn't need to, since Zotero is designed to support open standards and sites shouldn't need Zotero-specific code. (Ideally Zotero wouldn't need translators either.)

But if there are additional DOM events that Zotero should look for (by default or, for efficiency's sake, when translators explicitly register for them), those would be good to support.