Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
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,
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.
The same should be considered I guess for all major pages.
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.
I haven't had a chance yet to look over the new circ code so I can't comment on it now.
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.
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: