The main thing that we will need to think about in implementing JSON services is exactly what to expose. For the most part, VuFind works by sending record driver objects to the view and then loading templates that are specifically associated with those objects. This allows displays to adjust to display record-appropriate information and makes VuFind extremely flexible. The problem is that for JSON, you can't just convert a record driver object to JSON, and different drivers may need to expose different chunks of data.

Perhaps this is not a problem for what you have in mind -- not all of VuFind is so complicated -- but it's the main obstacle in building a generic VuFind API.  What serves as a strength for rendering a user interface is a weakness for dumping out raw data. You either need some complex JSON-specific code or you need to compromise what data is available to accommodate a "least common denominator" model of some sort.

Of course, in practice, this may not be as bad as it sounds in theory -- I've tried hard to make all of the VuFind record drivers as similar to one another as possible, and there is a lot of common ground -- but if we want to keep the extreme flexibility that we currently have, it doesn't hurt to keep crazy edge cases in mind when designing a JSON model.

Let me know if you'd like me to elaborate on any of this!

- Demian

From: Joe Atzberger []
Sent: Thursday, August 29, 2013 7:38 PM
To: Demian Katz
Cc: vufind-tech Tech
Subject: Re: [VuFind-Tech] JSON-data delivery

Revisiting the question of JSON data delivery, I find that Zend 2 has a JsonModel class that will probably speed a generic implementation:

It works w/ a JsonStrategy class that we would need to add in module.config.php.  It will probably be a while before I can get too deep with it, but that will be the next approach I attempt.


On Fri, Jul 19, 2013 at 2:39 PM, Demian Katz <> wrote:
I'm definitely in favor of reducing the use of the AjaxController in favor of more localized and pragmatic solutions.

Regarding the idea of AJAX-based tabs, this was discussed a long time ago but never went very far (though there is a 1.x patch in JIRA that gets us at least partway there). See

I like the fact that VuFind works pretty well without scripting, but we wouldn't necessarily have to break that to improve performance with AJAX -- the tab routine could return different results depending on whether the request isXmlHttpRequest() or not.

Regarding opportunistic preloading, my only concern is that we'd need to disable it for certain tabs -- I don't think we would want to trigger tons of calls to third-party APIs (e.g. reviews, excerpts) "just in case," especially since some services may have limits on them.

- Demian

From: Joe Atzberger []
Sent: Friday, July 19, 2013 1:15 PM
To: vufind-tech Tech
Subject: [VuFind-Tech] JSON-data delivery

Has there been any thought towards delivering more data from the backend to the client as JSON?  (For example, the details page description data.)  I'm not all-in for it, but I think it would be useful and wanted to air some thoughts about it.

Obviously this would not support javascript-less users (I don't think there are any such users anymore, even JAWS handles js).   But it would get us completely out of the intermingling of display and retrieval that happens, for example, in the record tabs.  One might argue it makes selenium or other testing more difficult, until you realize that testing the JSON itself is way easier.

I know my UI dev would love it.  

Performance: we would expect (at least 1) more request(s) per page.  But correctly and asynchronously delivered we could now separate out and properly cache data elements based on their volatility/longevity.  This would be unlike the current AjaxController that forces no-cache.  This approach would make it easier to, for example, opportunistically pre-load the data for non-current record tabs so that selecting them is instantaneous.  

Has anyone moved in this direction?  Are there Zend/PHP hangups I'm not thinking of?