On Mon, 2009-11-02 at 08:58 -0400, Grant Johnson wrote: > Alexander has facilitated the due date TIME so it is displayed in the > OPAC and Staff client for items that have "Hourly" locations. > Things like Hourly Reserves and Study Rooms. > > Click below and look for a Study Room that is "Not currently > available" > http://islandpines.roblib.upei.ca/opac/en-CA/skin/roblib/xml/rresult.xml?rt=title&tp=title&t=Group%2Bstudy%2Broom&l=4&d=2&f=&av=&ol=4 >
That's pretty cool. As usual, UPEI forges ahead and solves its own problem! I guess Alex is checking the location name in the returned acp (asset.copy) object and displaying the due time if it matches "hourly", which works well enough for your use case. The data is already there, it just needed somebody to use it, and hardcoding a check against the location name in the JavaScript itself does the job :) I do wonder if there's a good generalized way that we could bubble that behaviour upwards, so that libraries could turn the display of due times on or off depending on attributes of the copy itself and/or the copy location and/or the circulation attributes. For example, here I've been reluctant to display the expected return date for items because they're subject to being renewed - but if we were to check the "renewal_remaining" attribute of the "circ" object (which is part of the standard set of information returned for each copy in the copy display panel) and saw that it was "0", then we could safely say that it is supposed to be returned by the given date / time. That's no guarantee that it won't be overdue, of course... for a more consistent display, we could just display the due date / time and the number of renewals remaining in all cases. It should be easy enough to add another variable to the rdetails.js list of variables that control record display, to turn this sort of behaviour on and off. I guess the question that I'm hanging out there is, is that the approach that we want to continue to foster? At some point, I expect that there will miraculously (heh) be an OPAC that does more work on the server side, and it would be nice if we were storing these skin-level display decisions in the database so that they could be consistent across skins & display mechanisms for each org_unit, rather than being coded directly into one or more of the JavaScript files.
