Für diese Seite gibt es noch keine deutsche Übersetzung. Bitte lesen Sie solange die englische Version. Wir bitten Sie um Verständnis.
One the most annoying and tedious tasks of JSF programming is having to deal with labels and messages. AngularFaces takes the scare out of that.
Mind you, how often have you written something like this?
To make the tabular layout visible, the examples on this page deliberately draw lines around the grid cells.
That's two input fields, but six JSF components. Before the invention of @next and @previous, you also had to add ids to assign the label and the message to the input field. In fact, you still have to do so unless you're using PrimeFaces. Among other things, the ids make copying and pasting input fields a pain.
AngularFaces automatically adds the label and the error message to input fields. The label attribute of the input field is taken as the label caption:
In many cases, the label can be derived automatically from the bean attribute name. If you omit the label attribute of the input field, AngularFaces assumes the bean attribute name is a camel case version of the label. That's a useful feature for rapid prototyping - and even beyond if you see to it to chose expressive variable names. For example, the next example is as simple as can be:
As of AngularFaces 2.1, automatic addition of labels and messages requires a little preparation:
AngularFaces 2.1 takes a simplistic approach: labels always precede their input field, and messages always follow the input field. That's why the example uses a PrimeFaces panel grid with columns="3": The input field is accompanied by two components that are added automatically to the JSF view.
In a future version, AngularFaces is going to have more flexibility (such as putting labels above and messages below the input field).
There are three ways to influence the creation of labels and messages:
First, you can switch off the automatical creation of labels and messages by adding an attribute to <h:body> (or <h:body> if you prefer the relaxed syntax of AngularFaces).
Second, you can add the generation of labels and messages for each individual field:
The third possibility is to simply provide a label to the field. AngularFaces doesn't add a label if it recognizes there's already a label. So all you have to do is to add an outputLabel manually, and to set the for attribute. The same applies to the message attribute.
As of AngularFaces 2.1, this feature does not work with @next and @previous.
Suppressing message generation also disables the client side bean validation. You can fix it by adding a <puimessage />
tag to the <h:message /> tag. <puimessage /> is a client side widget implemented as an AngularJS directive. It
examines the css class of the associated input field and displays an error message if needed. If there's no error message to
display, it defaults to the optional "servermessage" attribute. Similarly, setting the context parameter clientSideMessages
to false suppresses the automatic replacement of <h:messages />
and <prime:messages />
by
a client-side messages component.
For instance, the HTML code generated by AngularFaces 2.1 to
display the label "number 2", a numeric input field and the error message looks like so:
Suppressing the automatic generation of labels doesn't break client side bean validation, but it also has a side effect. AngularFaces doesn't generate standard JSF or PrimeFaces labels, but <puilabel> that are partially created on the client side. They mimick the look and field of the host JSF framework, but they are also colored red if AngularJS considers the input field invalid. Standard JSF or PrimeFaces labels change their color only after an AJAX request (unless you activate the Client Side Validation feature of PrimeFaces 4+).
One the most annoying and tedious tasks of JSF programming is having to deal with labels and messages. AngularFaces takes the scare out of that.
Mind you, how often have you written something like this?
To make the tabular layout visible, the examples on this page deliberately draw lines around the grid cells.
That's two input fields, but six JSF components. Before the invention of @next and @previous, you also had to add ids to assign the label and the message to the input field. In fact, you still have to do so unless you're using PrimeFaces. Among other things, the ids make copying and pasting input fields a pain.
AngularFaces automatically adds the label and the error message to input fields. The label attribute of the input field is taken as the label caption:
In many cases, the label can be derived automatically from the bean attribute name. If you omit the label attribute of the input field, AngularFaces assumes the bean attribute name is a camel case version of the label. That's a useful feature for rapid prototyping - and even beyond if you see to it to chose expressive variable names. For example, the next example is as simple as can be:
As of AngularFaces 2.1, automatic addition of labels and messages requires a little preparation:
AngularFaces 2.1 takes a simplistic approach: labels always precede their input field, and messages always follow the input field. That's why the example uses a PrimeFaces panel grid with columns="3": The input field is accompanied by two components that are added automatically to the JSF view.
In a future version, AngularFaces is going to have more flexibility (such as putting labels above and messages below the input field).
There are three ways to influence the creation of labels and messages:
First, you can switch off the automatical creation of labels and messages by adding an attribute to <h:body> (or <h:body> if you prefer the relaxed syntax of AngularFaces).
Second, you can add the generation of labels and messages for each individual field:
The third possibility is to simply provide a label to the field. AngularFaces doesn't add a label if it recognizes there's already a label. So all you have to do is to add an outputLabel manually, and to set the for attribute. The same applies to the message attribute.
As of AngularFaces 2.1, this feature does not work with @next and @previous.
Suppressing message generation also disables the client side bean validation. You can fix it by adding a <puimessage />
tag to the <h:message /> tag. <puimessage /> is a client side widget implemented as an AngularJS directive. It
examines the css class of the associated input field and displays an error message if needed. If there's no error message to
display, it defaults to the optional "servermessage" attribute. Similarly, setting the context parameter clientSideMessages
to false suppresses the automatic replacement of <h:messages />
and <prime:messages />
by
a client-side messages component.
For instance, the HTML code generated by AngularFaces 2.1 to
display the label "number 2", a numeric input field and the error message looks like so:
Suppressing the automatic generation of labels doesn't break client side bean validation, but it also has a side effect. AngularFaces doesn't generate standard JSF or PrimeFaces labels, but <puilabel> that are partially created on the client side. They mimick the look and field of the host JSF framework, but they are also colored red if AngularJS considers the input field invalid. Standard JSF or PrimeFaces labels change their color only after an AJAX request (unless you activate the Client Side Validation feature of PrimeFaces 4+).
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.
One the most annoying and tedious tasks of JSF programming is having to deal with labels and messages. AngularFaces takes the scare out of that.
Mind you, how often have you written something like this?
To make the tabular layout visible, the examples on this page deliberately draw lines around the grid cells.
That's two input fields, but six JSF components. Before the invention of @next and @previous, you also had to add ids to assign the label and the message to the input field. In fact, you still have to do so unless you're using PrimeFaces. Among other things, the ids make copying and pasting input fields a pain.
AngularFaces automatically adds the label and the error message to input fields. The label attribute of the input field is taken as the label caption:
In many cases, the label can be derived automatically from the bean attribute name. If you omit the label attribute of the input field, AngularFaces assumes the bean attribute name is a camel case version of the label. That's a useful feature for rapid prototyping - and even beyond if you see to it to chose expressive variable names. For example, the next example is as simple as can be:
As of AngularFaces 2.1, automatic addition of labels and messages requires a little preparation:
AngularFaces 2.1 takes a simplistic approach: labels always precede their input field, and messages always follow the input field. That's why the example uses a PrimeFaces panel grid with columns="3": The input field is accompanied by two components that are added automatically to the JSF view.
In a future version, AngularFaces is going to have more flexibility (such as putting labels above and messages below the input field).
There are three ways to influence the creation of labels and messages:
First, you can switch off the automatical creation of labels and messages by adding an attribute to <h:body> (or <h:body> if you prefer the relaxed syntax of AngularFaces).
Second, you can add the generation of labels and messages for each individual field:
The third possibility is to simply provide a label to the field. AngularFaces doesn't add a label if it recognizes there's already a label. So all you have to do is to add an outputLabel manually, and to set the for attribute. The same applies to the message attribute.
As of AngularFaces 2.1, this feature does not work with @next and @previous.
Suppressing message generation also disables the client side bean validation. You can fix it by adding a <puimessage />
tag to the <h:message /> tag. <puimessage /> is a client side widget implemented as an AngularJS directive. It
examines the css class of the associated input field and displays an error message if needed. If there's no error message to
display, it defaults to the optional "servermessage" attribute. Similarly, setting the context parameter clientSideMessages
to false suppresses the automatic replacement of <h:messages />
and <prime:messages />
by
a client-side messages component.
For instance, the HTML code generated by AngularFaces 2.1 to
display the label "number 2", a numeric input field and the error message looks like so:
Suppressing the automatic generation of labels doesn't break client side bean validation, but it also has a side effect. AngularFaces doesn't generate standard JSF or PrimeFaces labels, but <puilabel> that are partially created on the client side. They mimick the look and field of the host JSF framework, but they are also colored red if AngularJS considers the input field invalid. Standard JSF or PrimeFaces labels change their color only after an AJAX request (unless you activate the Client Side Validation feature of PrimeFaces 4+).
Für diese Seite gibt es noch keine deutsche Übersetzung. Bitte lesen Sie solange die englische Version. Wir bitten Sie um Verständnis.
One the most annoying and tedious tasks of JSF programming is having to deal with labels and messages. AngularFaces takes the scare out of that.
Mind you, how often have you written something like this?
To make the tabular layout visible, the examples on this page deliberately draw lines around the grid cells.
That's two input fields, but six JSF components. Before the invention of @next and @previous, you also had to add ids to assign the label and the message to the input field. In fact, you still have to do so unless you're using PrimeFaces. Among other things, the ids make copying and pasting input fields a pain.
AngularFaces automatically adds the label and the error message to input fields. The label attribute of the input field is taken as the label caption:
In many cases, the label can be derived automatically from the bean attribute name. If you omit the label attribute of the input field, AngularFaces assumes the bean attribute name is a camel case version of the label. That's a useful feature for rapid prototyping - and even beyond if you see to it to chose expressive variable names. For example, the next example is as simple as can be:
As of AngularFaces 2.1, automatic addition of labels and messages requires a little preparation:
AngularFaces 2.1 takes a simplistic approach: labels always precede their input field, and messages always follow the input field. That's why the example uses a PrimeFaces panel grid with columns="3": The input field is accompanied by two components that are added automatically to the JSF view.
In a future version, AngularFaces is going to have more flexibility (such as putting labels above and messages below the input field).
There are three ways to influence the creation of labels and messages:
First, you can switch off the automatical creation of labels and messages by adding an attribute to <h:body> (or <h:body> if you prefer the relaxed syntax of AngularFaces).
Second, you can add the generation of labels and messages for each individual field:
The third possibility is to simply provide a label to the field. AngularFaces doesn't add a label if it recognizes there's already a label. So all you have to do is to add an outputLabel manually, and to set the for attribute. The same applies to the message attribute.
As of AngularFaces 2.1, this feature does not work with @next and @previous.
Suppressing message generation also disables the client side bean validation. You can fix it by adding a <puimessage />
tag to the <h:message /> tag. <puimessage /> is a client side widget implemented as an AngularJS directive. It
examines the css class of the associated input field and displays an error message if needed. If there's no error message to
display, it defaults to the optional "servermessage" attribute. Similarly, setting the context parameter clientSideMessages
to false suppresses the automatic replacement of <h:messages />
and <prime:messages />
by
a client-side messages component.
For instance, the HTML code generated by AngularFaces 2.1 to
display the label "number 2", a numeric input field and the error message looks like so:
Suppressing the automatic generation of labels doesn't break client side bean validation, but it also has a side effect. AngularFaces doesn't generate standard JSF or PrimeFaces labels, but <puilabel> that are partially created on the client side. They mimick the look and field of the host JSF framework, but they are also colored red if AngularJS considers the input field invalid. Standard JSF or PrimeFaces labels change their color only after an AJAX request (unless you activate the Client Side Validation feature of PrimeFaces 4+).