HTML and CSS Reference
In-Depth Information
"guid": {
"isPermaLink": "false",
"content": "USPA0326_2012_08_02_7_00_EDT"
}
}
}
}
}
}
As you can see in Listing 11-2, the request is pretty much the same. The only thing you change is the format in
which you want the data. In this case, you add an additional query param to the request called
format=json
.
This is,
again, pretty powerful in that it will allow ads to pull in data from various domains without the need for “white listing.”
Think about the possibilities when you can have your ad dynamically change without “actually” changing it.
■
there are client-side XmL-to-JsOn formatters (see
http://thomasfrank.se/xml_to_json.html
), but they
don't solve the cross-domain-policy issues.
Note
Content Formatting
So, you may be asking yourself, this dynamic data is all well and good, but don't I need to handle and condition the
data that gets injected into the ad? This is a great question, and the obvious answer is yes! Things like using swear
filters, adding ellipses, sizing text, and inserting code for line breaks all need to be taken into consideration.
First off, swear filters can typically be done on the back-end or server-side layer. Before that data gets inputted
into a service, it's generally best practice to condition for swears and negative comments against the brand. That being
said, it always good to reach out to the back-end developers to ensure this technique is in place. If it's not, Listing 11-3
shows a good client-side swear filter using JavaScript.
Listing 11-3.
JavaScript Swear Filter Example
<html>
<head>
<script type="text/javascript">
//Grow this list for as long as you wish...
var keyWords = [D'oh,'jeez','dagnabit','boo','agh','Golly'];
function replaceChars(chr,cnt) {
var s = '';
for (var i=0; i<cnt; i++) {
s += chr;
console.log(s);
}
return s;
}
