Javascript web service client parses HTML representations as entries, even if they're not
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Fix Released
|
High
|
Leonard Richardson |
Bug Description
Edwin wrote a function called parse_xml_entry which tears apart a default XHTML representation of an entry and makes a Javascript object out of it, the same way that the web service client currently turns a JSON representation of an entry into a Javascript object.
The problem is that the default XHTML representation is just that--a default. It's not necessarily a <dl> tag with a bunch of <dt> tags underneath it. It could be any HTML at all. And even if it is a <dl> tag, it doesn't make sense to tear it apart. If you need an Entry object, you can just request a JSON representation. XHTML representations are intended for display as part of web pages. So parse_xml_entry shouldn't even exist. The response, or its responseText, or responseXML (I'm not sure which) should be passed directly into the callback method, which is responsible for integrating the HTML data into the web page.
But, I'm guessing Edwin didn't write this code for no reason. So I'm filing this bug so that we can work it out. We need to 1) figure out how to do what Edwin wants to do, 2) figure out whether we should be passing the callback the response object itself, response.
Changed in launchpad-foundations: | |
status: | Fix Committed → Fix Released |
I've associated a branch with this bug which changes wrap_resource_ on_success. When the client requests an XHTML representation, it passes response. responseText into the callback method instead of calling parse_xml_entry. This is a branch that Edwin can hack on (to make his code call parse_xml_entry itself) and Bjorn can use to get his work done.
In IRC Edwin explained that he created parse_xml_entry because he was sending a PATCH request that modified a single field, and he needed the HTML representation of that specific field. This is exactly the use case for bug 369887, which will let you PATCH a single field and get a representation of just that field. Once I fix 369887, we can get rid of parse_xml_entry.