[OPEN-ILS-DEV] git repository web view issues
Hi guys, I just noticed this morning that the web interface for the git repository has a problem (typo?). When I go to a specific repo such as: http://git.evergreen-ils.org/?p=Evergreen.git;a=summary I am getting the error: XML Parsing Error: undefined entity Location: http://git.evergreen-ils.org/?p=Evergreen.git;a=summary Line Number 41, Column 20:div class=titlenbsp;/div ---^ Thanks, Robert Robert Soulliere, BA (Hons), MLIS Systems Librarian Mohawk College Library robert.soulli...@mohawkcollege.ca Telephone: 905 575 1212 x3936 Fax: 905 575 2011 This E-mail contains privileged and confidential information intended only for the individual or entity named in the message. If the reader of this message is not the intended recipient, or the agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is prohibited. If this communication was received in error, please notify the sender by reply E-mail immediately, and delete and destroy the original message.
Re: [OPEN-ILS-DEV] git repository web view issues
When I go to a specific repo such as: http://git.evergreen-ils.org/?p=Evergreen.git;a=summary Hrmm, works for me in chrome. XML Parsing Error: undefined entity Location: http://git.evergreen-ils.org/?p=Evergreen.git;a=summary Line Number 41, Column 20:div class=titlenbsp;/div That's a weird one for an HTML page. -- Jason Etheridge | VP, Tactical Development | Equinox Software, Inc. / Your Library's Guide to Open Source | phone: 1-877-OPEN-ILS (673-6457) | email: ja...@esilibrary.com | web: http://www.esilibrary.com Equinox is going to New Orleans! Please visit us at booth 550 at ALA Annual to learn more about Koha and Evergreen.
Re: [OPEN-ILS-DEV] git repository web view issues
For what it is worth, I still get this in Firefox 4, the first time I load the git web interface after the cache has been cleared I get this same error for a brief instant, then the rest of the page loads and everything is fine. I think parts of the page may be dynamically loaded, causing the xhtml parser to freak out when the xml syntax isn't correct because it hasn't been fully loaded yet; but that is just a guess. Cheers, Joseph -- Public Key: [0xF8462E1593141C16]http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xF8462E1593141C16 For a successful technology, reality must take precedence over public relations, for nature cannot be fooled. - Richard Feynman On Wed, Jun 22, 2011 at 7:06 AM, Soulliere, Robert robert.soulli...@mohawkcollege.ca wrote: It turned out to be a local browser issues. The issue occurred in Firefox 3.6 running on Ubuntu. I upgraded Firefox and did not restart the browser after the upgrade. After restarting Firefox, it works well. Opps,;-) Thanks, Robert Robert Soulliere, BA (Hons), MLIS Systems Librarian Mohawk College Library robert.soulli...@mohawkcollege.ca Telephone: 905 575 1212 x3936 Fax: 905 575 2011 From: open-ils-dev-boun...@list.georgialibraries.org [ open-ils-dev-boun...@list.georgialibraries.org] On Behalf Of Jason Etheridge [ja...@esilibrary.com] Sent: June 22, 2011 9:01 AM To: Evergreen Development Discussion List Subject: Re: [OPEN-ILS-DEV] git repository web view issues When I go to a specific repo such as: http://git.evergreen-ils.org/?p=Evergreen.git;a=summary Hrmm, works for me in chrome. XML Parsing Error: undefined entity Location: http://git.evergreen-ils.org/?p=Evergreen.git;a=summary Line Number 41, Column 20:div class=titlenbsp;/div That's a weird one for an HTML page. -- Jason Etheridge | VP, Tactical Development | Equinox Software, Inc. / Your Library's Guide to Open Source | phone: 1-877-OPEN-ILS (673-6457) | email: ja...@esilibrary.com | web: http://www.esilibrary.com Equinox is going to New Orleans! Please visit us at booth 550 at ALA Annual to learn more about Koha and Evergreen. This E-mail contains privileged and confidential information intended only for the individual or entity named in the message. If the reader of this message is not the intended recipient, or the agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is prohibited. If this communication was received in error, please notify the sender by reply E-mail immediately, and delete and destroy the original message.
Re: [OPEN-ILS-DEV] More unicode patches for SIPServer
Your commit message mentions that the testcases appear to be invalid and that they came from some guide; I don't see any samples in the SIP2 Protocol Definition so I guess that's some other resource? Yeah, I think it was called the SIP Implementer's Handbook. Among other things it gave a nice detailed step-by-step computation of checksums... for a trivial example... on a system with several loaded assumptions. For almost every other request/response, it included these problematic checksums I could not reproduce. I suspect the example lines were adjusted (e.g. to change the username/password) and the checksums were not updated. And this was supposed to be my guide *out* of the mess. they should absolutely be removed from the unit tests and replaced with actual examples from the wild - ideally identifying what make and model of self-check or SIP client the examples came from. Indeed. It's not clear to me what you're suggesting then. [...] I can add unit tests that match our environment That is pretty much exactly what I'm asking for. I don't mind breaking hypothetical systems in the wild if we can at least ask them what values are you getting for the tests that compute OK on ours? And what does the *extensive* debugging output look like? Thanks for the reply and persistence. --joe
Re: [OPEN-ILS-DEV] More unicode patches for SIPServer
Quoting Joe Atzberger ohioc...@gmail.com: Yeah, I think it was called the SIP Implementer's Handbook. You are probably referring to the SIP2 Interface Developer's Guide? It is utter rubbish. The table of contents is not even correct in most editions. There are more bad examples in there than good. I'd suggest pitching it and never thinking about it again. All I can say is that the %U, %16U, and %16C options all seem to be working for us with our clients. I don't know what character sets our clients are using, but we have some from Envisionware, Librarica/Cassie, 3M, and others. I might be able to dig some up for unit testing purposes, but most of our messages are going to contain real information, so I guess we'd need to somehow convince our members with different clients to do some tests with a dummy account for us. Jason Stephenson Merrimack Valley Library Consortium
Re: [OPEN-ILS-DEV] Rethinking no Dojo in TT OPAC
On 6/14/11 6:11 PM, Dan Scott wrote: On Tue, Jun 14, 2011 at 01:44:36PM -0400, Lebbeous Fogle-Weekley wrote: snip If Dojo's available, there's a temptation to do all the work with client-side logic, disenfranchising a small but real number of users. And if Dojo's available, it's a small step to Dijit. Nobody really benefits from fade-ins and spinny things when they just want to find some books or pay a fine, so I think we definitely want to leave that out. And then there's the existing JS fieldmapper and Agreed. other stuff that we might want to reach for, let alone the Javascript for Google Analytics and ChiliFresh and so on that we kind of already need to use anyway, and before you know it 31 kb is 3100 kb, which has a real impact on usability for *lots* of users. Except, we're talking about it right now. So we could easily agree as a team that Evergreen's TT OPAC will never include Dijit or Dojox. Anybody else can fork Evergreen and include amazing spinny things, but we have the ability to say that we won't support anything beyond Dojo base. Like Lebbeous, I'm not anti-Dojo, particularly for integrating added content, but I don't like the idea of requiring it for the baseline catalog. It's not a fear of Dojo or 31KB, but a fear of what it means for future development. For the sake of discussion, I'd like to propose a significantly more strict set of boundaries than Dan's on the use of Dojo, should we decide to go this route: * It can only be used for retrieving and displaying remote content, i.e. content that comes from another server, whose response time is not controlled by Evergreen. * Dojo and any code that depends on it is only loaded on pages that offer such added content and then only when the added content is enabled. I realize this might seem excessive, but my fear is if we open the door to Dojo anywhere, even if we're forbidding Dijit, Dojox, etc., the OPAC will unwittingly evolve into a JS-driven interface, even if we're not using it to initially retrieve the data. The temptation seems too strong. I would sincerely like to avoid that. -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / Your Library's Guide to Open Source | phone: 877-OPEN-ILS (673-6457) | email: erick...@esilibrary.com | web: http://esilibrary.com Equinox is going to New Orleans! Please visit us at booth 550 at ALA Annual to learn more about Koha and Evergreen.
