During the JSF lifecycle state will be restored at the beginning of a request (if any state is available) and state will be saved at the end of a request (if any state is available).
Why is it important to know what happens during request processing? Well, if you know how JSF state saving works you can optimize your application to perform better.
The following blog articles are part of the JSF Converter series
In the previous blog entry you learned how to write your own converter. Say you want to distribute this converter to others. How can you make sure the JSF runtime knows about the converter without needing to add it to the faces-config.xml of the web application.
Writing you own converter is a pretty straight forward process. It really comes down to implementing the Converter API.
Say you want to write a converter that will convert colors. Lets assume we support, "Red", "Green" and "Blue".
How would you use the JSF DateTimeConverter?
If you are working with dates you probably have had a need to display them in the correct format, or even had to parse them? Well, lets start off with using dateStyle. The example below will use the "long" date style as defined by the server Locale. Valid values are "default", "short", "medium", "long", and "full".
How do you use the JSF NumberConverter?
If you are outputting a value, how would you show a currency code along with it?
See what the JSF Validator API is about!
The definition of a Converter according to the Converter interface:
Introduction to JSF Converters
During the JSF lifecycle each input value needs to be converted. As such the JSF runtime allows you to write converters that will take care of that during request processing.
The following blog articles are part of the JSF Validator series
In the previous blog entry titled "Writing your own validator" you learned how to write a validator and hook it up for validation. At that time we made it all work using the faces-config.xml file. There is however another way, which we will describe below!