Catálogo de publicaciones - libros

This chapter acts as a mini-guide for the rest of the book; it also gives you a foundation for your continued journey into the world of JSF beyond this book.

One of the key differentiators JSF has over other view technologies is its openness and ability to adopt newly emerging technologies such as XUL, HTC, and Ajax, as well as other future view technologies. JSF has clear benefits over other technologies because an application built with JSF can continue to live while the surrounding technologies pass away and new ones arise. JSF can reduce maintenance costs for application development since there is only one programming model needed—JSF and Java—even though the systems may require different user agents such as Telnet, instant messaging, mobile agents, browsers, and other types of agents such as barcode readers.

This chapter touched on details that make up a JSF application—JSF components, navigation model, and backend logic via managed beans. We also explored the ins and outs of the JSF component model and its clear separation between presentation and behavior, and we discussed the structure of JSF components—UIComponent, Renderer, the renderer-specific subclass RenderKit, and the JSP tag handler. The chapter also detailed the JSF request lifecycle on initial request and postback, including navigation.

It is crucial to understand the separation between presentation and behavior in order to grasp the full potential of JSF components.

This chapter gave you a blueprint and an understanding of what is required to write a JSF custom component. It covered topics including creating Renderers, creating renderer-specific subclasses, using external resources, registering component objects, and creating JSP tag handlers and TLDs. In later chapters, you will leverage this knowledge as the foundation for building more advanced JSF components.

The structure of how to build components will remain the same throughout the book. First you analyze the markup needed to create the intended behavior and user interface. Then you create the client-specific Renderer with all attributes needed for your component. Optionally, but recommended, you create the renderer-specific subclass that the application developer can use to customize the component at runtime. Finally, you implement support for the page description of choice—JSP. You should also now understand how to use ValueBinding and MethodBinding and how to support these concepts in your own JSF tag handlers.

This chapter extended the blueprint given to you in Chapter 2. The blueprint now contains seven steps covering everything from analyzing the UI prototype to writing the JSP TLD. Remember that in most cases you will need to use only five out of these seven steps, since the most common scenario is to extend an existing behavioral UIComponent rather than to create a new one.

As part of the blueprint, you also created a client-specific Renderer (HtmlShowOneDeckRenderer) with all the attributes needed for the component and a renderer-specific subclass (ProShowOneDeck). Finally, you implemented support for the page description of choice—JSP. All of this followed the same pattern introduced in Chapter 2; as you probably noticed, it is not hard to create a component if you have a blueprint to follow, although there is a certain amount of repetition.

From this chapter, you also gained an understanding of the JSF event model and how to implement support for custom events and listeners in your own JSF tag handlers.

This chapter gave you some insight into three of the market’s leading view technologies for RIAs: XUL, HTC, and Ajax. These technologies have proven they are more than capable of providing users with rich and responsive interfaces. The chapter also touched on the issues with these technologies such as lack of standards, platform support, and maintenance.

Looking ahead, the potential for JSF as a technology is unlimited. Component developers can provide the community with a wide range of components supporting technologies from HTML to XUL, including wireless and even character-based solutions; your imagination is the only limit.

The chapter showed how to build reusable components with XBL and HTC, as well as how to implement event handling, how to implement encapsulation, and how to embed custom components in a page using the supported implementations (CSS and import) provided by the different technologies. You also gained knowledge about Ajax and its key player, the XMLHttpRequest object. For more information about these technologies, please visit the Mozilla Web site (http://www.mozilla.org), the Microsoft MSDN Web site (http://msdn.microsoft.com/), and Wikipedia.org (http://en.wikipedia.org/wiki/AJAX).

As a new open source project, Weblets has tremendous potential to become a de facto standard that provides a generic and configurable resource-loading facility for web clients and the JSF component community. The key differentiators from the installables approach are the simplified packaging of JSF components and their resources and a minimal overhead of installing and setting up JSF component libraries for a particular web application project.

This chapter explored a new way of packaging resources with JSF components. You should now be able to leverage weblets in your own component library by including a suitable weblets-config.xml file and using the weblet:// protocol-style syntax to reference webletmanaged resources.

You should now understand how weblets integrate with JSF, understand the concepts used to package additional resources, and know how to set up and optimize an application to use these resources.

In this chapter, we discussed how to use Ajax in general terms and as part of JSF, and we also talked about what pros and cons it brings to the plate. We also covered different architectural approaches implementing Ajax support in JSF—PPR and DR. In addition, we discussed potential pitfalls of Ajax, such as file upload support, and how to solve them in the context of JSF.

We explored how to use two open source projects—the Dojo toolkit and D project—to Ajax enable your ProShowOneDeck component and prove that providing richer functionality in well-defined and easy-to-use JSF components is not hard. With the use of rich toolkits such as Dojo and D, the number of resource files is increasing, and weblet functionality provides an easy way to package your additional resources into the same library as your components.

From this chapter, you gained an understanding of how to Ajax enable JSF components using available resources and now have a deeper understanding of the contentType issue between JSP and JSF. You also gained knowledge about how you solve the contentType issue and allow JSF to control the contentType, which will give you the opportunity to support multiple content types when needed.

This chapter discussed how you can use Ajax to fetch data and how you can leverage the JSF managed bean facility as a data source.

The chapter also covered the different XMLHttpRequest response types—responseText and responseXML—that you can use to return the result from the server. We also showed you how to use the eval() function to efficiently parse JSON-syntax responses.

We covered a new open source project called Mabon that extends JSF to provide a custom lifecycle that invokes a managed bean method remotely and then transfers the result to the client using JSON syntax.

From this chapter, we hope you have gained an understanding of how to Ajax-enable data fetch for your JSF components; in addition, you should now have a deeper understanding of object-oriented JavaScript programming techniques. You should now also be able to create your own custom validator.

The Mozilla Web site says it best: XUL is cool! We definitely recommend that component developers look at XUL as an alternative rendering technology for rich Web clients. Although initially it may seem overwhelming to create JSF components using XUL, it is actually pretty straightforward as long as you follow a well-defined blueprint.

A direct benefit of using XUL is the declarative component model you have at your disposal. XUL also enhances performance and reduces the amount of JavaScript you have to create and maintain.

We hope this chapter gave you a clear understanding that HTML is not the end of the road and that the limits of what we can do with the J2EE framework are sometimes in our own heads!

You have now completed four different solutions for the ProInputDate and ProShowOneDeck components. You used traditional HTML Renderers, HTML Ajax Renderers, XUL Ajax Renderers, and HTC Ajax Renderers. Who said JSF is not a rich client development platform?

With the experience you have gained so far, it is important to keep in mind that an application developer might be using your component in combination with other technologies that you did not even consider. You need to keep the abstraction for the application developer, and although tempting, you should not design your component with a dependency on the client-side rendered markup, since you do not have control over other components’ generated markup.

One of things you want you to take from this chapter is that you should stay open to new and controversial suggestions; do not get locked into one technology stack because it is what you know or is what others tell you is the latest and greatest. Always ask yourself, “How can this solve my problems?”

After reading this chapter, you should have a clear understanding of what HTC is and how you can leverage it in your component design.

In this chapter, we showed you how easy it is to provide dynamic RenderKit switching with JSF. By using a component-driven design, application developers can build applications for any type of user agent without being impacted by the underlying client markup.

In the previous chapters, we demonstrated how you can write Renderers that support regular HTML, Ajax, XUL, and HTC. Some component writers are already looking at even more client technologies to provide application developers with a common programming model regardless of the user agent. A good example of this is the Oracle ADF Faces component library. It has built-in support for HTML, RIAs, character-based solutions, instant messenger clients such as Gaim and Yahoo, PDAs, and so on. The MyFaces open source project also provides an alternative RenderKit to HTML—the WML RenderKit.

Now that you know how to create reusable rich Internet components with JSF and how to use multiple RenderKits, we hope you will apply the techniques you have learned in this book to create your own custom components and build RIAs with JSF.