Best Practice Best Practice Guidelines Guidelines in using Ajax with Java in using Ajax with Java Server FacesServer Faces

Craig R. McClanahanCraig R. McClanahanSenior Staff EngineerSenior Staff EngineerSun Microsystems, IncSun Microsystems, Inc.

2

Agenda• Background• Best practice guidelines• Examples:> Auto Complete Text Component> DynaFaces AJAX Zones

• Summary• Resources

BackgroundsBackgrounds

4

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

5

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

Best Practice GuidelinesBest Practice Guidelines

7

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

Architectural Decisions:Architectural Decisions:To Ajax or Not to Ajax?To Ajax or Not to Ajax?

9

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

10

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

11

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

Architectural Decisions:Architectural Decisions:Render Markup+Code orRender Markup+Code orJust Code?Just Code?

13

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

14

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

Architectural Decisions:Architectural Decisions:Manage Client sideManage Client sideInteractionsInteractions

16

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

17

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

Architectural Decisions:Architectural Decisions:Access Static ResourcesAccess Static Resources

19

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

20

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

Architectural Decisions:Architectural Decisions:Asynchronous CallbacksAsynchronous Callbacks

22

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 :-)

23

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 ...

24

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

25

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

ExamplesExamples

27

Examples• Auto Complete Text Field Component• Dynamic Faces (DynaFaces) AJAX Zones

28

Auto Complete Text Field

29

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

30

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

DemoDemo

32

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

Summary &Summary &ResourcesResources

34

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

35

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/

Best Practice Best Practice Guidelines Guidelines in using Ajax with Java in using Ajax with Java Server FacesServer Faces

Craig R. McClanahanCraig R. McClanahanSenior Staff EngineerSenior Staff EngineerSun Microsystems, IncSun Microsystems, Inc.