Für diese Seite gibt es noch keine deutsche Übersetzung. Bitte lesen Sie solange die englische Version. Wir bitten Sie um Verständnis.
The AngularFaces way of doing AJAX
Most of the time AngularFaces replaces the original AJAX requests by its own, highly-optimized requests.
Synchronizing values between AngularJS scope and JSF beans works in both ways. The values of the input fields are transmitted back to the server, no matter whether you do a regular HTML request, a JSF AJAX request or the optimized AngularFaces request.
AngularFaces provides an advanced way of AJAX requests. Typically, they use a lot less network bandwidth, and they are faster than traditional JSF AJAX request. To activate an AngularFaces AJAX, you have to do two simple preparations:
- Add an JSF AJAX button that includes a special update region: "angular". You've already seen this above:
- Add the id "angular" to the <h:body>.
Note that the id "angular" doesn't really mark an ordinary update region. It's a virtual id. If AngularFaces sees the id, it replaces the default update response generated by JSF by a highly-optimized response that updates only the scope values. However, there are also drawbacks to this approach. For instance, the <prime:growl> tag isn't updated. I don't consider this a disadvantage: the idea of AngularFaces is to move such functionality to the client. Validation and presenting error messages in particular is Angular's job.
Note that AngularFaces 2.1 adds special support for <h:messages /> and <prime:messages />. Both tags
are silently replaced by client-side widgets, and the content of these widgets is part of the AngularFaces AJAX requests.
Beware of rendered="false"
It's a bad idea to use rendered="false" to hide a component in an AngularFaces page. AngularFaces uses optimized AJAX responses that update the
variables of the scope, but nothing else. Hence, if you show or hide something on the server side using the rendered attribute, the
HTML page is never updated. Better use ng-show, ng-hide or - as shown above - either style or styleClass.
Under the hood
This is an example of an AngularFaces AJAX response:Basically, the response consists of a single Javascript function that's send to the client. By contrast, a traditional JSF response replaces a part of the DOM tree. You can easily spot the difference, even though I've omitted a lot of the code in the example:
The AngularFaces way of doing AJAX
Most of the time AngularFaces replaces the original AJAX requests by its own, highly-optimized requests.
Synchronizing values between AngularJS scope and JSF beans works in both ways. The values of the input fields are transmitted back to the server, no matter whether you do a regular HTML request, a JSF AJAX request or the optimized AngularFaces request.
AngularFaces provides an advanced way of AJAX requests. Typically, they use a lot less network bandwidth, and they are faster than traditional JSF AJAX request. To activate an AngularFaces AJAX, you have to do two simple preparations:
- Add an JSF AJAX button that includes a special update region: "angular". You've already seen this above:
- Add the id "angular" to the <h:body>.
Note that the id "angular" doesn't really mark an ordinary update region. It's a virtual id. If AngularFaces sees the id, it replaces the default update response generated by JSF by a highly-optimized response that updates only the scope values. However, there are also drawbacks to this approach. For instance, the <prime:growl> tag isn't updated. I don't consider this a disadvantage: the idea of AngularFaces is to move such functionality to the client. Validation and presenting error messages in particular is Angular's job.
Note that AngularFaces 2.1 adds special support for <h:messages /> and <prime:messages />. Both tags
are silently replaced by client-side widgets, and the content of these widgets is part of the AngularFaces AJAX requests.
Beware of rendered="false"
It's a bad idea to use rendered="false" to hide a component in an AngularFaces page. AngularFaces uses optimized AJAX responses that update the
variables of the scope, but nothing else. Hence, if you show or hide something on the server side using the rendered attribute, the
HTML page is never updated. Better use ng-show, ng-hide or - as shown above - either style or styleClass.
Under the hood
This is an example of an AngularFaces AJAX response:Basically, the response consists of a single Javascript function that's send to the client. By contrast, a traditional JSF response replaces a part of the DOM tree. You can easily spot the difference, even though I've omitted a lot of the code in the example:
A página ainda não foi traduzido para o Português. Por favor, leia a tradução em Inglês. Pedimos desculpas por qualquer inconveniente.
The AngularFaces way of doing AJAX
Most of the time AngularFaces replaces the original AJAX requests by its own, highly-optimized requests.
Synchronizing values between AngularJS scope and JSF beans works in both ways. The values of the input fields are transmitted back to the server, no matter whether you do a regular HTML request, a JSF AJAX request or the optimized AngularFaces request.
AngularFaces provides an advanced way of AJAX requests. Typically, they use a lot less network bandwidth, and they are faster than traditional JSF AJAX request. To activate an AngularFaces AJAX, you have to do two simple preparations:
- Add an JSF AJAX button that includes a special update region: "angular". You've already seen this above:
- Add the id "angular" to the <h:body>.
Note that the id "angular" doesn't really mark an ordinary update region. It's a virtual id. If AngularFaces sees the id, it replaces the default update response generated by JSF by a highly-optimized response that updates only the scope values. However, there are also drawbacks to this approach. For instance, the <prime:growl> tag isn't updated. I don't consider this a disadvantage: the idea of AngularFaces is to move such functionality to the client. Validation and presenting error messages in particular is Angular's job.
Note that AngularFaces 2.1 adds special support for <h:messages /> and <prime:messages />. Both tags
are silently replaced by client-side widgets, and the content of these widgets is part of the AngularFaces AJAX requests.
Beware of rendered="false"
It's a bad idea to use rendered="false" to hide a component in an AngularFaces page. AngularFaces uses optimized AJAX responses that update the
variables of the scope, but nothing else. Hence, if you show or hide something on the server side using the rendered attribute, the
HTML page is never updated. Better use ng-show, ng-hide or - as shown above - either style or styleClass.
Under the hood
This is an example of an AngularFaces AJAX response:Basically, the response consists of a single Javascript function that's send to the client. By contrast, a traditional JSF response replaces a part of the DOM tree. You can easily spot the difference, even though I've omitted a lot of the code in the example:
Für diese Seite gibt es noch keine deutsche Übersetzung. Bitte lesen Sie solange die englische Version. Wir bitten Sie um Verständnis.
The AngularFaces way of doing AJAX
Most of the time AngularFaces replaces the original AJAX requests by its own, highly-optimized requests.
Synchronizing values between AngularJS scope and JSF beans works in both ways. The values of the input fields are transmitted back to the server, no matter whether you do a regular HTML request, a JSF AJAX request or the optimized AngularFaces request.
AngularFaces provides an advanced way of AJAX requests. Typically, they use a lot less network bandwidth, and they are faster than traditional JSF AJAX request. To activate an AngularFaces AJAX, you have to do two simple preparations:
- Add an JSF AJAX button that includes a special update region: "angular". You've already seen this above:
- Add the id "angular" to the <h:body>.
Note that the id "angular" doesn't really mark an ordinary update region. It's a virtual id. If AngularFaces sees the id, it replaces the default update response generated by JSF by a highly-optimized response that updates only the scope values. However, there are also drawbacks to this approach. For instance, the <prime:growl> tag isn't updated. I don't consider this a disadvantage: the idea of AngularFaces is to move such functionality to the client. Validation and presenting error messages in particular is Angular's job.
Note that AngularFaces 2.1 adds special support for <h:messages /> and <prime:messages />. Both tags
are silently replaced by client-side widgets, and the content of these widgets is part of the AngularFaces AJAX requests.
Beware of rendered="false"
It's a bad idea to use rendered="false" to hide a component in an AngularFaces page. AngularFaces uses optimized AJAX responses that update the
variables of the scope, but nothing else. Hence, if you show or hide something on the server side using the rendered attribute, the
HTML page is never updated. Better use ng-show, ng-hide or - as shown above - either style or styleClass.
Under the hood
This is an example of an AngularFaces AJAX response:Basically, the response consists of a single Javascript function that's send to the client. By contrast, a traditional JSF response replaces a part of the DOM tree. You can easily spot the difference, even though I've omitted a lot of the code in the example: