best practice best practice guidelines guidelines in using
DESCRIPTION
TRANSCRIPT
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.