Für diese Seite gibt es noch keine deutsche Übersetzung. Bitte lesen Sie solange die englische Version. Wir bitten Sie um Verständnis.
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:
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.
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
.
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:
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:
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.
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
.
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.
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:
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.
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
.
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.
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:
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.
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
.
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: