Your SlideShare is downloading. ×
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Best Practice Best Practice Guidelines Guidelines in using ...
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Best Practice Best Practice Guidelines Guidelines in using ...

765

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
765
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
20
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Best Practice Guidelines in using Ajax with Java Server Faces Craig R. McClanahan Senior Staff Engineer Sun Microsystems, Inc. Inc
  • 2. Agenda • Background • Best practice guidelines • Examples: > Auto Complete Text Component > DynaFaces AJAX Zones • Summary • Resources 2
  • 3. Backgrounds
  • 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 4
  • 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 5
  • 6. Best 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 7
  • 8. Architectural Decisions: 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 9
  • 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 10
  • 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 11
  • 12. Architectural Decisions: Render Markup+Code or 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 13
  • 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 14
  • 15. Architectural Decisions: Manage Client side Interactions
  • 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 16
  • 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 17
  • 18. Architectural Decisions: Access 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 19
  • 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 20
  • 21. Architectural Decisions: Asynchronous 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 :-) 22
  • 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 ... 23
  • 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 24
  • 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 25
  • 26. Examples
  • 27. Examples • Auto Complete Text Field Component • Dynamic Faces (DynaFaces) AJAX Zones 27
  • 28. Auto Complete Text Field 28
  • 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 29
  • 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 30
  • 31. Demo
  • 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 32
  • 33. Summary & Resources
  • 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 34
  • 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/ 35
  • 36. Best Practice Guidelines in using Ajax with Java Server Faces Craig R. McClanahan Senior Staff Engineer Sun Microsystems, Inc. Inc

×