|
From: Dave D. <dr...@cr...> - 2004-11-08 16:53:05
|
On Nov 6, 2004, at 4:51 PM, Frank Kurzawa wrote: > 1. SAXParseException: The entity name must immediately follow the '&' > in the entity reference. > Some MLS listings end up with ampersands in their data, e.g. in the > property description. Unfortunately, SAX just throws up over these. This is bad... really bad. > I've not much experience with tweaking SAX, but the only obvious way > that I > see to deal with this is to modify the characters() method in the > SearchResultHandler to escape any ampersands in the <DATA> content. 'Tis too late by the point characters() is called, I imagine. > Is there a better approach? The best method is to yell at your MLS. The SAX parsers I've seen are not that lenient on XML (and they shouldn't be). AFAIK, there's no SAX compliant XML parser that will allow ampersands to be legal. You see, software outside of real estate tend to follow their specifications. :) A SAX parser wouldn't be an XML parser if it allowed ampersands. I suppose one way around this is to wrap the XML input stream and replace ampersands *before* it gets to the XML parser, thus making sure the data is XML before it hits SAX. But as this has got to be a performance hit, I'd say this is not something that RETS client should do by default, if at all. > 2. client.LogoutResponse - Invalid logout response key: Logged Out -> > <null> > a. Actually, I couldn't even get this output until I first modified > KeyValueResponse.HandleRetsResponse(). The method assumes that the > RetsResponse Element actually has a "=" in the content. If the "=" is > missing then a catastrophic null pointer exception occurs. > I fixed this by modifying the HandleRetsResponse() method to substitute > the string "<null>" if there is no equals. Just so I know exactly what you are talking about, what is the full response you are getting from your server here (cut and paste it, if you can)? > b. Beyond that, if the server returns anything other than > "ConnectTime", "Billing", or "SignOffMessage", then > LogoutResponse.handleKeyValue() chooses to fail catastrophically, which > locks CART out of the ability to work with some RETS servers. > I handled this by modifying the handleKeyValue() method to simply log > an > error in this situation. The stuff I checked in Friday should handle this. > Are my chosen modifications the best way to handle these issues? I'm > starting to feel like I need to continually tweak rets-client every > time > I work with another (non-compliant) RETS server out there. Okay... which RETS server are you using? They are terribly sloppy, and should not be allowed to use the word "RETS" when describing their product. -Dave |