Closed cjjuice closed 8 years ago
I'm curious which MLS this is for? Both this and #138 appear to be breaking the rets standard. This one seems relatively painless to support, but #138 seems much more error prone to try and support both cases.
@dougcole new to the whole MLS thing but I am hitting an endpoint on mlspin.com. Not sure if that answers your question
I just checked against our MLSPIN endpoint and got this in the raw response text:
<RETS ReplyCode=\"0\" ReplyText=\"Operation Successful\">\r\n<DELIMITER value=\"09\" />
Can you confirm whether you're inspecting the raw response text or the nokigiri object?
Response:
<RETS ReplyCode="0" ReplyText="Operation Successful"> <DELIMITER Value="09"/> <!-- ECT -->
Until I made this fix was getting an parsing issue where it just made the entire thing a one key because it didn't recognize the delimiter.
Ah, we integrate with a different mlspin server.
I'm not a huge fan of this but unless @dougcole objects I think this seems like a useful addition.
Now the ternary operator has been blown up I'd prefer we extract this into a function like:
def parse_delimiter(doc)
delimiter_node = doc.at("//DELIMITER")
return TAB unless delimiter_node
#mlspin returns value instead of "Value"
value = delimiter_node.attr(:value) || delimiter_node.attr("Value")
delimiter = Regexp.new(Regexp.escape(value.to_i.chr))
if delimiter == // || delimiter == /,/
raise InvalidDelimiter, "Empty or invalid delimiter found, unable to parse."
else
delimiter
end
end
Yeah function is cleaner.
This seems to have sputtered out, happy to merge after the suggested refactor, but closing for now as the pull request seems to be abandoned.
The current implementation does not support an uppercase attribute on the delimiter element.