This document discusses migrating from JSF 1.1 to JSF 2.0. It highlights new features in JSF 2.0 including Facelets templating, Ajax support, and improved validation. When upgrading, issues may include custom components mixing technologies and JSP/JSF lifecycle conflicts. The document recommends converting JSPs to Facelets to avoid these issues, reusing existing components where possible, and using backing beans to remove logic from the view. Proper use of backing beans, custom tags, and initialization methods can help with code organization.

1. Migrating from JSF1 to JSF2. 1 by Tahir Raza

2. Highlight 2 Introduction Technology Matrix JSF 2.0 Features Introduction to Facelets Issues encountered during JSF upgrade JSF Ajax Libraries Going forward

3. Technology Matrix 3

5. Easy creation of custom components

6. Ajax

7. Expand the request processing lifecycle to be aware of Ajax. http://www.jsfmatrix.net/

8. State Saving

9. Separate the "build the tree" and "render the tree" processes into two separate lifecycle phases.

10. Allow for partial tree traversel during lifecycle execution via Ajax.

11. Performance

12. New scopes

13. Flash Scope

14. View Scope

15. No configuration needed – Magic of Annotations

16. Managed Bean Annotations

17. Component Annotations

18. Improved Validation

19. Validationgroups

20. Implicit Navigation

21. Strategic additions to the Standard HTML RenderKit: Date Picker, Tree, Tab View, File Upload components.

23. Lots of Custom components in the code

24. Components mix HTML, JSP and JSF

25. RequestDispatcher.include() – issue

26. Lots of scriplets

27. JSP and JSF lifecycle issues

28. Tag-Lib issues:

29. Facelet implementation already part of JSF2

31. Understanding implementation

32. JSF; AJAX; Web Galileo usage

33. Rendering of static & dynamic content including portlets.

34. Comparing JSF 1.1 and JSF 2.0 changes.

35. Lot of changes since 1.1 (1.2, 2.0)

36. Change of paradigm Get rid of JSPs and bring Facelets. Faster? JSP conflicts with JSF lifecycle Remove all logic from UI and put where it belongs

38. Apache MyFaces, ICE Faces, Web Galileo, RichFaces, PrimeFaces …

39. Narrowed to

40. Compared the following frameworks: Apache MyFaces; Ice Faces; RichFaces

41. Conclusion

42. Best to use MyFaces 2.0 and RichFaces 3.3.2 -> Good future support

47. Convert all JSPs to Facelets (XHTML)

48. Try to re-use the existing components

49. Convert the TLDs to *TAGLIB.XML

51. Replacing Scriptlet Code with a Backing Bean (cont.) 12 Facelet code: <a href="#{standardHeaderManagedBean.partnerUrl}" target="top">…</a>

52. Replacing Scriptlet Code Using Unified EL 13 Example Sciptlet Code: <% if (!GenericValidator.isBlankOrNull(partnerBO.getPartnerUrl())) { … } else { … } %> Put the above code in BackingBean (ManagedBean) as much a possible.

53. Converting JSPs Pages to Facelet Pages (2) 14 Conditional Statements in JSPs. <c:choose/>, <c:if/> and <c:forEach> can be avoided unless we are sure it would not create problems with the compile-time vs render-time issue. It can be replaced with <ui:fragmentrendrered=“#{boolean}”/> <c:forEach/> can be replaced with <ui:repeat/> MyFaces Tomahawk also has some components that can be use for such conditions. Read: http://www.ilikespam.com/blog/c:foreach-vs-ui:repeat-in-facelets http://drewdev.blogspot.com/2008/03/build-time-vs-render-time.html

55. Find common functionality that can be shared and refactor to common beans vs. implementing one backing bean per view

56. Most backing beans should be request scoped (as opposed to session or application scope)

57. Look for opportunities to create custom tags that can help with code reuse

58. Page initialization can happen with the following:

59. Constructor