Element costEl = doc.createElement("cost");
costEl.appendChild(
doc.createTextNode(String.valueOf(deal.getCost())));
dealEl.appendChild(fromEl);
dealEl.appendChild(toEl);
dealEl.appendChild(costEl);
rootEl.appendChild(dealEl);
}
return new DOMSource(doc);
}
}
Hopefully you can begin to see the issue with generating the XML representation from the
plain old Java object (POJO) model.
The concrete HomePagethat we created, extends Spring’s base AbstractXsltViewand over-
rides the required createXsltSource()method. The processing in the abstract superclass will
use this Sourceobject as the source (of course) of the transformation.
■CautionIn Spring 1.2,AbstractView.createXsltSource was not marked abstract, thereby not
requiringyou to implement it in your subclass and enforcing the desired contract. This method was added
in Spring 1.2 to replace the legacy createDomNodemethod that returns a DOM object. Because only one
of those methods should be implemented by subclasses, and backward compatibility was required for
1.1 subclasses, this wasn’t possible and createDomNodewas simply deprecated instead. In Spring 1.3,
createDomNodehas been removed and createXsltSourcemade abstract.
Transforming the XML Source
Listing 8-34 shows a textual representation of the DOM that we built up in the preceding
method, assuming two special deals had been returned for our home page.
Listing 8-34.The Raw XML Prior to Transformation
<?xml version="1.0" encoding="UTF-8"?>
<specials>
<deal>
<from>London</from>
<to>New York</from>
<cost>300</cost>
</deal>
<deal>
<from>Paris</from>
252 CHAPTER 8 ■SUPPORTED VIEW TYPES