Beginnings of the rework in circulation

  • Micah Stetson

    Micah Stetson - 2010-03-16

    I just pushed changes to bitbucket making circ/index.php, circ/mbr_search.php, and circ/mbr_view.php use the new form I'm thinking of for the server-side code.  One of the big benefits of the architecture I have in mind is that it gives us the option of making a page transition (i.e. in the browser history) whenever we want without ever forcing us to make one.  I want Fred to be able to make a JS application that uses the server-side code only as needed and never loads a new HTML page from the server.  But I still want the default interface to have page transitions where it makes sense to me.  What I'm proposing will (I think) let us have our cake and eat it too.

    Here's the idea: the old "pages" are the API calls.  If you make a normal request, say GET /circ/mbr_view.php?mbrid=5, then you'll get a complete HTML page representing that member.  If you make the same request with the additional parameter "format=json", then you get a JSON data structure representing the requested member.  So if you want to link to a member's page, then just give the user a normal link to ../circ/mbr_view.php?mbrid=5.  But if you want to do something on the client side and you need to retrieve a member's data, do $.getJSON('../circ/mbr_view.php?mbrid=5&format=json').

    The same idea works for member search.  If you want to link the user to an HTML page listing all members with 'smith' in their names, link to ../circ/mbr_search.php?rpt_terms=name&rpt_terms=0&rpt_terms=smith.  If you want to get the first page of results in JSON format, do $.getJSON('../circ/mbr_search.php?rpt_terms=name&rpt_terms=0&rpt_terms=smith&format=json').  The returned JSON structure includes not only the first page of results, but also information on the number of pages available.

    (I know the parameters to mbr_search are ugly.  They're a consequence of how it's implemented directly as a report.  It should almost certainly be made more friendly, but that wasn't my focus today.)

    The way this is implemented is that the PHP files on the server make a structure suitable for passing to json_encode().  Then, if the 'format=json' parameter is present, the JSON is just spit out at the client.  If the parameter isn't present, then the data structure is passed to a template that produces the HTML.  The beautiful thing here is that there is essentially no mixing of HTML and PHP.  All the logic of search is done in circ/mbr_search.php, and all the formatting is done either on the client (if we're doing an AJAX request) or in circ/mbr_search.jsont.

    I'd also like to note that this is simplifying things considerably.  It's been quite a while since I wrote the current circ code, and it looks pretty bad to me.  It's amazing what a couple of years will do to your thinking about code quality.  This move, when it's complete, will let us remove a ton of complicated, difficult-to-follow code and replace it with a smaller amount of simpler code.

    Please read the updated files and let me know your thoughts.  Thanks,


  • Luuk Jansen

    Luuk Jansen - 2010-03-17

    Well, that sounds like a good approach to me.
    I do think maybe it is worth thinking about some-kind of convention about when to do a 'full-page' load and when not.

    E.g. I can see the point of just doing a full page load on accessing a member's info, but then if for example something is checked out by a member I think using AJAX would be good, of if you want to see the borrowing history of a member etc. you could use a javascript popup or something like that (how do you call them, I know it is roxbox in Joomla CMS, whcih is a modification of an API to do this.)

    The same should be considered I guess for all major pages.

  • Fred LaPlante

    Fred LaPlante - 2010-03-17

    Some of what is proposed is actually in place to handle the OPAC functions. ../catalog/iblio_search.php now looks at the GET parameters whenever it starts and if they are present it can handle searches by barcode, phrase or bibid whatever is passed.

    As to popups they have been a part of JavaScript from the beggining. My feeling on all this is that if a screen needs to view 'supplemental' information it should create a popup window for the purpose. If you do that you need no pass any information to it at all other than perhaps to let it know it is a popup. All information in the parent window is available to the popup so it can simply reguest what it needs as it needs it and you can forget passing much of anything.  Using a popup simplifies the browser 'back' button issue as the current 'Go Back' buttons would be simply switched via JavaScript to close the popup and, voila, you are back in the display you started from.

    I haven't had a chance yet to look over the new circ code so I can't comment on it now.


  • Micah Stetson

    Micah Stetson - 2010-03-31

    I'll be interested to hear what you guys have to say about the code itself, when you get a chance.  Fred, I realize that the current pages take GET parameters already - I'm not changing that.  What's new is the format=json parameter and the flexibility that gives us.

    Luuk, you're right that we need to have some concrete idea of when page transitions should or should not occur.  I just haven't gotten that far yet.

    For the record, I hate almost all pop ups that use a separate OS window.  I want web pages to stay in one tab unless I tell them otherwise.  I think Luuk is talking about "pop ups" that are really just a <div> (or some such) made to act like a sub-window using CSS and JS.  I like those better than real pop ups, since they stay in their tab.


  • Luuk Jansen

    Luuk Jansen - 2010-03-31

    Yes, I meant a 'fancy' div. I use Roxbox on the Joomla CMS, which works very nicely.
    I think apart from the CMS plugin, there is a standalone version as well (a bit down on the page) in case you are interested:


Log in to post a comment.