Consider the following fragment of HTML code:
<div id="myCarInfo"> <h1 title="data:lastUpdated"> <span>data:make</span> <span>data:model</span> <span>data:year</span> </h1> </div>
Consider the following JavaScript Data Object (JSON used for illustrative purposes)
var carInfoObject = { make: "BMW", model: "325i", year: "2002", lastUpdated: new Date(481516234200) }
IBDOM, thru the custom-defined function $e(), allows you to do this:
$e("myCarInfo").populate(carInfoObject);
IBDOM augments all HTML Elements it comes across with a number of useful methods. populate() happens to be one of them. If Protoype.js is loaded, elements retrieved thru $e() get augmented with both the Prototype Element.methods, and IBDOM's methods.
While there are numerous mechanisms and enabling frameworks for retrieving data asynchronously into an HTML document, the basic task of injecting a significant amount of data into a document remains a typically laborious process.
To circumvent this laborious process, many developers instead opt to asynchronously retrieve "markup fragments", which are made of data that has already been fully-injected into the necessary HTML that can simply be inserted "as-is" into the main document.
While this approach works well enough, there are many use cases where it still makes more sense to only retrieve pure data from the server.
IBDOM was designed to alleviate this tedium, while fully-embracing standard-compliant documents, by providing an unobtrusive mechanism to "map data values" to JavaScript Objects.
Developers who work with the Direct Web Remoting framework are used to getting JavaScript Objects back from proxied method calls. While DWR already provides useful utilities to simplify the process of injecting these objects into a document, IBDOM complements this functionality.
Read more about working with DWR.
Think of any time you've found yourself cobbling together long strings of HTML, to eventually set the .innerHTML of an element. Markup can now be kept away from scripting.