Best Practice

Guidelines
in using Ajax with Java
Server Faces

Craig R. McClanahan
Senior Staff Engineer
Sun Microsystems, Inc.
Inc
Agenda
• Background
• Best practice guidelines
• Examples:
> Auto Complete Text Component
> DynaFaces AJAX Zones
• Summary
• Resources

2
Backgrounds
Background
• Building AJAX based applications is easy ...
> If you are a JavaScript guru
> If you have memorized the entire DOM API
> If you own and study books on DHTML, JavaScript, CSS,
AJAX, and useful hacks for each technology
• Building AJAX based applications is hard ...
> If you come from a mostly static HTML/CSS background
> If you are comfortable with traditional web application
architectures built around an HTTP POST
> If your primary use of JavaScript is cut-n-paste of cute
animations and other cool in-page behaviors
4
Background
• Can we make this process easier for mere mortals?
• Classic computer science answer: encapsulation
> Hide functionality behind simple building blocks
> Provide a framework for assembling complicated things
out of simple things
> Embed the encapsulations inside development tools that
can do some of the grunt work
• JavaServer Faces components encapsulate AJAX
technologies

5
Best Practice Guidelines
Architectural Decisions
• To AJAX or not to AJAX, that is the question ...
• Render “markup + code” or just “code”?
• Manage client side interactions
• Access static resources
• Asynchronous callbacks – client side view
• Asynchronous callbacks – server side view

7
Architectural Decisions:
To Ajax or Not to Ajax?
To AJAX Or Not To AJAX ...
• First inclination when talking about AJAX and JSF:
> Create AJAX-aware versions of every component
• When does this make sense?
> Individual component needs remote access for state:
– Assumption: visualization depends on server state changes
– Example: Progress Bar (for server side process)
– Example: RSS News Headlines (that dynamically change)
– Example: “Is this username already taken?” validation
> Individual component needs remote access for data:
– Assumption: too much data to load with the initial page
– Examples: Auto Complete Text Field, Table, Tree Control
9
To AJAX Or Not To AJAX ...
• When does this not make sense?
> Primarily interested in partial page submit:
– Grab a subset of the input elements on this page, and ...
– Submit them to update server side state ...
– Without requiring a full page submit
> Primarily interested in partial page refresh:
– Respond to a partial page submit by ...
– Updating part of the current view ...
– Without requiring a full page redisplay
• Frameworks exist to provide these facilities for any
JavaServer Faces component
> We will see an example later
10
To AJAX Or Not To AJAX ...
• Recommendations:
> Design or use AJAX enabled components when
necessary
> Use frameworks to manage partial page submit and
partial page refresh scenarios

11
Architectural Decisions:
Render Markup+Code or
Just Code?
Render Markup+Code Or Just Code
• First inclination when talking about AJAX and JSF:
> Render all the markup and related JavaScript code for
each component individually
> Note: Applies to non-AJAX components also
• When does this make sense?
> Markup is very simple and/or highly use case specific
> Corresponding JavaScript code is very simple
> Note: Hybrid solution is also feasible:
– Generate custom markup per component
– Reference JavaScript libraries for code common to all
occurrences of a particular component

13
Render “Markup+Code” Or Just “Code”?
• When does that not make sense?
> Markup is complex
> Corresponding JavaScript code is complex
> Using a JavaScript “widget” library for rendering
• Recommendations:
> Use JavaScript “widget” libraries when feasible:
– JSF renders JS code to create and configure the widget
> Factor per-component JavaScript into static resources:
– Leverage client side caching
– Ensure that required resources are loaded transparently
– Ensure that required resources are loaded once per page
14
Architectural Decisions:
Manage Client side
Interactions
Manage Client Side Interactions
• First inclination when talking about AJAX and JSF:
> Create custom JavaScript APIs to interact with other
client side components
> Note: Applies to non-AJAX components also
• When does this make sense?
> Providing functionality above and beyond standard
JavaScript event handlers
– Such as an asynchronous callback to update state
> Encapsulating complex interactions
– Such as coordinated updates of multiple client side elements

16
Manage Client Side Interactions
• When does this not make sense?
> When standard JavaScript event handlers are sufficient
– Leverage developer familiarity
> When you want to support “unanticipated” interactions
– Document enough about internal architecture to allow this
• Recommendations:
> Use standard client side interaction paradigms:
– JavaScript object per widget
– Standard event handlers where feasible
> Consider event-driven or publish/subscribe paradigms
> JSF Specific – be aware of component id generation
algorithms
17
Architectural Decisions:
Access Static Resources
Access Static Resources
• First inclination when talking about AJAX and JSF:
> Embed all required JavaScript and stylesheets in the
generated markup of each component
> Note: Applies to non-AJAX components also
• When does this make sense?
> When the required JavaScript is very simple and/or use
case specific
> When the required stylesheet information is very simple
and use case specific

19
Access Static Resources
• When does this not make sense?
> JavaScript for a particular component can be factored
into a common library
> CSS styles can be factored into common stylesheets that
can be overridden by the developer
• Recommendations:
> Factor JavaScript and CSS into static resources
> Ensure that only one copy of each resource gets loaded
into a single page
> Trigger runtime loading of static resources transparently
– Developer should not need to care that your component needs
a particular script file or stylesheet
20
Architectural Decisions:
Asynchronous Callbacks
Asynchronous Callbacks – Client
• First inclination when talking about AJAX and JSF:
> Hand code the XMLHttpRequest handling individually for
each component
• When does this make sense?
> Basically never :-)
• When does this not make sense?
> Basically always :-)

22
Asynchronous Callbacks – Client
• Recommendations:
> Encapsulate XMLHttpRequest handling into common
JavaScript functions
– Per component, or ideally, per library
> Leverage existing JavaScript frameworks:
– More elegant client side APIs
– Hide browser dependencies
> Leverage facilities of the server side framework:
– See next section ...

23
Asynchronous Callbacks – Server
• First inclination when talking about AJAX and JSF:
> Write a custom servlet for each component's
asynchronous callback handler
• When does this make sense?
> In simple use cases
> When the client side is not your JSF component library
• When does this not make sense?
> Asynchronous callback needs to access and/or update
the JSF component tree for the current view
> Need to manage data serialization and deserialization
– Affects client side also
24
Asynchronous Callbacks – Server
• Recommendations:
> Leverage JSF server side framework capabilities:
– JSF component state for PPS/PPR use cases
– Managed beans for simple IoC requirements
– Can integrate more complex frameworks for non-simple use cases
– Method binding expresions to invoke server side logic
> Utilize libraries and frameworks for data transport:
– Common formats: XML and JSON
– Minimize requirements imposed on the server side developer
as well as the client side developer
> Support non-JSF-component clients:
– Not every UI will be created with JSF, or even Java
– Not every callback will be from a browser
25
Examples
Examples
• Auto Complete Text Field Component
• Dynamic Faces (DynaFaces) AJAX Zones

27
Auto Complete Text Field

28
Auto Complete Text Field
• To AJAX Or Not To AJAX:
> Provide embedded AJAX functionality
• Render Markup+Code Or Just Markup:
> Hybrid: custom (simple) markup, shared JavaScript
• Client Side Interactions:
> Component creates well-known DOM element ids
> Standard JavaScript events plus two custom ones
• Access Static Resources
> Shale Remoting library

29
Auto Complete Text Field
• Asynchronous Callbacks – Client Side:
> Standard JavaScript object per component instance
> Utilize DOJO Toolkit for asynchronous IO
> Simple XML data format
• Asynchronous Callbacks – Server Side:
> No need to access JSF component tree state
> Component-provided managed bean for callback handler
> Component invokes application-provided method (with
simple API) to provide data
– Application developer does not need to know the gory details

30
Demo
Dynamic Faces (DynaFaces)
• Extension framework for JavaServer Faces 1.1/1.2
> Built on top of standard extension APIs
• Delivers solutions for several of our focus areas:
> To AJAX Or Not To AJAX:
– AJAX Zones for partial page refresh scenarios
– Works with non-AJAXified components
> Client Side Interactions:
– Trigger asynchronous callbacks programmatically
– Deferred transactions for post-callback event handling
> Server Side Interactions:
– Fire server side event handlers
– Manage client-server data formatting
32
Summary &
Resources
Summary
• JavaServer Faces was originally targeted as a
traditional server-side-markup-generation
component framework
• JavaServer Faces can be leveraged in many ways
to build AJAX-based web applications
• JavaServer Faces supports the use of AJAX
techniques on components not specifically designed
for AJAX interactions

34
Resources
• JavaServer Faces:
> http://java.sun.com/javaee/javaserverfaces/
• Java BluePrints Catalog:
> http://java.sun.com/reference/blueprints/
• AJAX Developer Resource Center:
> http://developers.sun.com/ajax/
• Apache Shale Framework:
> http://shale.apache.org/
• DOJO Toolkit:
> http://dojotoolkit.org/
35
Best Practice
Guidelines
in using Ajax with Java
Server Faces

Craig R. McClanahan
Senior Staff Engineer
Sun Microsystems, Inc.
Inc