User Tools

Site Tools


dev:browser_staff:dev_notes

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
dev:browser_staff:dev_notes [2014/07/02 09:36] ericksondev:browser_staff:dev_notes [2022/02/10 13:34] (current) – external edit 127.0.0.1
Line 2: Line 2:
  
 Explorations and milestones for the browser staff client development project. Explorations and milestones for the browser staff client development project.
 +
 +==== 2014-07-18 ====
 +Author: Bill Erickson
 +
 +=== Integrating Existing HTML Interfaces ===
 +
 +After expressing my own concerns (annoyances?) about using iframes for HTML UI integration, Dan Wells replied to the list, "I don’t think we should rule out using iframes for catalog integration.  Iframes are actually pretty close in many respects to the way the catalog 'integrates' into the current (XUL) staff client."  Point taken and ran with...
 +
 +I've integrated patron registration and the catalog into the browser client in a manner similar to the XUL client using iframes.  In most cases, it's as simple as passing in "xulG" functions to mimic the ones on offer by the XUL client.  In a few cases, we have to edit the original UIs (e.g. avoiding inline hrefs for "oils:<nowiki>//</nowiki>" and the like), but thus far that has been the exception.  I'm still working through the different behaviors, but I have no reason to think we can't port all of the actions from the XUL client over to the browser.
 +
 +== One Fly in the Ointment ==
 +
 +I have run into one snag with this approach related to how WebKit (Chrome/Safari) browsers handle browsing history with iframes in conjunction with HTML5 pushstate.  Basically, after navigating forward in the iframe, then clicking the Back button in the browser, instead of going to the previous iframe page as one would expect (and as Firefox does), the browser navigates to the previous pushsate URL, which will always be the URL of the containing page, which effectively does nothing, since that URL doesn't change.  
 +
 +If this sounds like gibberish, you can see it in effect on my dev site.  Simply perform a record search, then try using the back button to return to the search page:
 +
 +https://bill-dev2.esilibrary.com/eg/staff/cat/catalog/index  (admin / demo123)
 +
 +Unlike here, where I'm using an iframe but no pushstate routing.  Using the Back button after a search actually returns the user to the previous page.
 +
 +https://bill-dev2.esilibrary.com/~berick/cat.html
 +
 +I have yet to track down a bug entry for this (I did find a mention at  https://github.com/jashkenas/backbone/issues/799), though I'm fairly sure this is in fact a browser bug.  BTW, I did try wiring up handlers for myIframe.contentWindow.history.back(), etc. but they resulted the same behavior.  I'll keep an eye out for any developments on this.
  
 ==== 2014-07-02 ==== ==== 2014-07-02 ====
dev/browser_staff/dev_notes.1404308219.txt.gz · Last modified: 2022/02/10 13:34 (external edit)

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki

© 2008-2022 GPLS and others. Evergreen is open source software, freely licensed under GNU GPLv2 or later.
The Evergreen Project is a U.S. 501(c)3 non-profit organization.