If you would like to boost ADF UI performance, you should look into client side validation and formatting options possible to be done in ADF UI. Today I will describe how you can implement client side converter, to format number value on client side, without making request to the server. Same approach could be used to implement client side validators. You can raise error message and it will be assigned to UI field in the same way, just like any standard ADF error message. While this approach is documented long ago in Oracle ADF developer guide - How To Create Client Side Converter, it is not well known and not often used.
Client side converter is attached to ADF UI field through JSF tag, it points to custom converter ID (make sure autoSubmit=false is set, we don't want request to the server on value change):
Custom converter is defined in Faces Configuration file, it points to custom converter class:
Converter class is responsible to load JavaScript file, where number formatting logic is implemented. Also we have an option to pass initialization parameters:
Example of client side converter logic (to format numbers) code in JS:
Formatting happens on the client, no request to the server is done. User enters value and navigates out of the field - value is formatted:
If fractional part is incorrect, error raised from converter is displayed same as any other error in ADF - attached to the field:
If value is invalid - error is displayed too, this simple validation error comes from JS converter. Request is processed on the client, no call to the server:
Server side formatter in ADF BC is still required. When data is fetched from DB, ADF BC server side formatter is applied to transform data to correct format (this happens when data is fetched and doesn't affect end user performance):
Custom number formatter implemented in ADF BC (read more about it: Generic BigDecimal Formatter in ADF 12.2.1.1):
Download sample application - ADFFormattingApp.zip.
Client side converter is attached to ADF UI field through JSF tag, it points to custom converter ID (make sure autoSubmit=false is set, we don't want request to the server on value change):
Custom converter is defined in Faces Configuration file, it points to custom converter class:
Converter class is responsible to load JavaScript file, where number formatting logic is implemented. Also we have an option to pass initialization parameters:
Example of client side converter logic (to format numbers) code in JS:
Formatting happens on the client, no request to the server is done. User enters value and navigates out of the field - value is formatted:
If fractional part is incorrect, error raised from converter is displayed same as any other error in ADF - attached to the field:
If value is invalid - error is displayed too, this simple validation error comes from JS converter. Request is processed on the client, no call to the server:
Server side formatter in ADF BC is still required. When data is fetched from DB, ADF BC server side formatter is applied to transform data to correct format (this happens when data is fetched and doesn't affect end user performance):
Custom number formatter implemented in ADF BC (read more about it: Generic BigDecimal Formatter in ADF 12.2.1.1):
Download sample application - ADFFormattingApp.zip.
2 comments:
Additional information here, as it was discussed with you:
For Converter java class it is proper to implement Converter and ClientConverter interfaces instead of extending internal class, as it is done in example.
import javax.faces.convert.Converter;
import org.apache.myfaces.trinidad.convert.ClientConverter;
More info at:
https://docs.oracle.com/middleware/1212/adf/ADFUI/af_validate.htm#ADFUI342
Thanks for correction (internal class was added by mistype).
Andrejus
Post a Comment