Web Services
Enterprise Mashup Services
Part 2: Combining JSF and mashup services to make mashup components
Mar. 17, 2007 01:30 PM
Digg This!
Page 2 of 3
« previous page
next page »
Behavior
Component classes characterize behavior
and extend the javax.faces.component.UIComponentBase class or one of
its subclasses (Listing 2). Each component class is also defined in the
faces-config.xml file shown as follows:
<component>
<component-type>
com.thepeninsulasedge.components.MapPanel
</component-type>
<component-class>
com.thepeninsulasedge.components.UIMap
</component-class>
</component>
Presentation
A component's presentation is
delegated to a separate class that extends the
javax.faces.render.Renderer class (Listing 3). A renderer produces a
graphical representation that need not be implemented with HTML. The
presentation could be represented by XUL, ASK, Telnet, or any number of
protocols. For our purposes the renderer is used to generate HTML and
JavaScript. The JavaScript produced by the renderer is used to post to
URLs defined by the Shale Framework as well as consume the Google Maps
API. Note that this compromises the clean separation between
presentation and behavior implemented by the JSF component architecture
because behavior is now also defined in the renderer. Unfortunately
this is a necessary evil when mixing JSF with AJAX. Each renderer class
must also be defined in the faces-config.xml file shown as follows:
<render-kit>
<renderer>
<component-family>
com.thepeninsulasedge.components.MapPanel
</component-family>
<renderer-type>com.thepeninsulasedge.components.Map</renderer-type>
<renderer-class>
com.thepeninsulasedge.components.MapRenderer
</renderer-class>
</renderer>
</render-kit>
Tag Definition
The JSP tag representing the
component is defined by a subclass of the
javax.faces.webapp.UIComponentTag class (Listing 4) and a tag library
descriptor (TLD) - an XML file that provides metadata for the tag
(Listing 5). The TLD should be registered in the web.xml file shown as
follows:
<jsp-config>
<taglib>
<taglib-uri>http://thepeninsulasedge.com/jsf</taglib-uri>
<taglib-location>/WEB-INF/pc.tld</taglib-location>
</taglib>
</jsp-config>
Developing Mashup Components with JSF and Shale
As
previously mentioned, the intent of this article is to build a JSF
component that encapsulates a mashup service and provides the ability
to link JavaScript events that represent interactions with the
encapsulated service to methods associated with a managed bean. Now
that you have a basic understanding of the core technologies involved,
let's take a look at an example of a mashup component.
<tpe:map id="gmap"
initLat="#{mapbean.initLat}"
initLng="#{mapbean.initLng}"
zoomLevel="#{mapbean.initZoom}"
inlineStyle="width:500px;height:500px;"
key="#{mapbean.key}"
model="#{mapbean}"/>
The tpe:map component represents a wrapper for the
Google Maps API, and it generates the HTML and JavaScript shown in
Listing 6. The rendered component (shown in Figure 4)
provides a generic interface to the API and can easily be changed to
represent another mapping API such as Yahoo! Maps. To do so, simply
replace the renderer class (Listing 3) provided in the example with one
that generates the HTML and JavaScript required to display a map from
Yahoo! Maps. User interactions with the Google Maps API, such as
zooming, panning, and clicking, are trapped by JavaScript events, which
in turn request a URL that is mapped to a method associated with a
managed bean.
The map component has two required attributes: key
and model. The key attribute is the account identifier for the Google
Maps service. You can request a key at www.google.com/apis/maps/signup.html.
The model attribute requires a subclass of the
com.thepeninsulasedge.components.model.MapModel abstract object
(Listing 7). A concrete implementation of this object represents the
model for the map component. The object contains geospatial points in
the form of com.thepeninsulasedge.components.model.GeoPoint objects
(Listing 8) that represent visual markers on the map. The object also
contains methods or event handlers to respond to events fired by the
map.
Page 2 of 3
« previous page
next page »
About Ric SmithRic Smith is director, business and product strategy at Kaazing. provides Kaazing Corporation with a wealth of experience in product management and consulting for enterprise products and services. Prior to joining Kaazing, Ric was a principal product manager for Oracle's Fusion Middleware at Oracle's Headquarters in Redwood Shores, CA. In his role as a Principal Product Manager he was responsible for the evangelism and product direction of Oracle's AJAX and Java EE Web Tier offerings. Before joining the Fusion Middleware team, Ric worked for Oracle's consulting business as a principal consultant where he led development of mission-critical applications for prominent organizations within the defense/intelligence industry. In addition, Ric won consecutive awards for technical achievement for each year of his tenure as a consultant. Ric is a frequent speaker at international events and has written articles featured in leading industry publications such as Java Developer's Journal and AJAXWorld Magazine. He is also a representative to the OpenAjax Alliance and an honors graduate of the University of Arizona.