qr code scanner java app Introducing JBoss Seam in Java

Drawer QR Code 2d barcode in Java Introducing JBoss Seam

@Column(name = "`PASSWORD`", length = 12, nullable = false) private String password; @Column(name = "FIRSTNAME", length = 255, nullable = false) private String firstname; @Column(name = "LASTNAME", length = 255, nullable = false) private String lastname; ...}

You apply only two Hibernate Validator annotations: the @Length and @Pattern validators. These validators have attributes such as the maximum and minimum length, or a regular expression pattern (see java.util.regex.Pattern). A list of all built-in validation annotations can be found in the Hibernate Validator reference documentation in the Hibernate Annotations package. You can also easily write your own annotations. All validation annotations have a message attribute. This message is displayed next to the form field if a validation failure occurs. You can add more validation annotations that also check the password, the first name, and the last name of the User. Note that the length attribute of the USERNAME @Column annotation has been removed. Thanks to the length validation annotation, Hibernate s schema export tool now knows that a VARCHAR(16) must be created in the database schema. On the other hand, the nullable = false attribute stays, for the generation of a NOT NULL database column constraint. (You could use a @NotNull validation annotation from Hibernate Validator, but JSF already checks that field for you: The form field is required="true".) After you add the validation annotations to User, submitting the registration form with incomplete values displays error messages, as shown in figure 17.11. The registration feature is now complete; users can create new accounts. What doesn t seem to be perfect are the error messages. If you try the code, you ll see that the error messages aren t as nice as the ones shown in figure 17.11. The fields that require input have an ugly _id23: Field input is required message, instead. Also, is it a good idea to put English error messages into your entity classes, even if they re in annotation metadata Instead of replacing only the default JSF error messages (which include the automatically generated widget identifiers), let s isolate all user interface messages and also allow users to switch languages.

The first step toward a multilanguage application is a language switcher let s say, a link the user can click in the top menu of the application. Seam has a localeSelector component (it lives in the session context) that makes this easy:

<h:form> <h:panelGroup> <h:outputText value="#{messages['SelectLanguage']}"/>: <h:commandLink value="EN" action="#{localeSelector.selectLanguage('en')}"/> | <h:commandLink value="DE" action="#{localeSelector.selectLanguage('de')}"/> </h:panelGroup> </h:form>

This little form has two hyperlinks, EN and DE. Users can click the links to switch the application s interface between English and German. The link actions are bound to the localeSelector.selectLanguage() method, with literal arguments.

These arguments, en and de, are ISO language codes; see the Javadoc for java.util.Locale. But that isn t all that happens here. When the form is rendered, the #{messages['SelectLanguage']} expression is evaluated, and the output of that expression is rendered as text, before the comand links. The output of this expression is something like Select your language: . Where does it come from Clearly, messages is a Seam component; it lives in the session context. It represents a map of externalized messages; SelectLanguage is a key this map is searched for. If the map contains a value for that key, the value is printed out. Otherwise, SelectLanguage is printed verbatim. You can use the messages component anywhere you can write an expression that resolves Seam components (which is almost anywhere). This component is a convenient handle to a Java resource bundle, which is a complicated term that means key/value pairs in a .properties file. Seam automatically reads messages.properties from the root of your classpath into the messages component. However, the actual filename depends on the currently selected locale. If a user clicks the DE link, the file that is searched in the classpath is named messages_de.properties. If English is the active language (which is the default, depending on the JSF configuration and browser), the file that is loaded is messages_en.properties. Here is a snippet of messages_en.properties:

SelectLanguage = Select language: PleaseRegisterHint = Create a new account... SelectUsernameAndPassword = Select a username and password PasswordVerify = Repeat password PasswordVerifyField = Controlpassword Firstname = First name Lastname = Last name Email = E-mail address TooShortOrLongUsername = Minimum 3, maximum 16 characters. NotValidUsername = Invalid name! {TooShortOrLongUsername} PasswordVerifyFailed = Passwords didn't match, try again. UserAlreadyExists = A user with this name already exists. SuccessfulRegistration = Registration complete, please log in: DoRegister = Register Cancel = Cancel # Override JSF defaults javax.faces.component.UIInput.REQUIRED = This field cannot be empty.

The last line overrides the default JSF validation error message for the input field widget. The syntax {Key} is useful if you want to combine message; the TooShortOrLongUsername message is appended to the NotValidUsername message.