Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Learning from Reverse Engineered JSF Components (Part 2)

DZone's Guide to

Learning from Reverse Engineered JSF Components (Part 2)

· Java Zone ·
Free Resource

How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.

The latest release of the NAL ("name and location") component mentioned yesterday, now at 1.4 (since yesterday) comes with support for validation ("required" attribute in line 5 below):

<body>
 <f:view>
  <h:form>
   <h1><h:outputText value="JavaServer Faces" /></h1>
   <nal:inputNAL required="true" value="#{NalBean.nal}" />
   <h:messages />
  <h:commandButton action="submit" value="Submit"/>
  </h:form>
</f:view>
</body>

This will result in the following error message being rendered if even one of the input fields is not filled in:

Customize the message by means of the "requiredMessage" attribute. Alternatively, instead of setting the "required" attribute, which sets validation for the entire component, you can use the JSF Validator functionality to create per-field validation (line 6 below):

<body>
  <f:view>
    <h:form>
      <h1><h:outputText value="JavaServer Faces" /></h1>
      <nal:inputNAL value="#{NalBean.nal}" >
        <f:validator validatorId="nal.NalValidator"/>
      </nal:inputNAL>
      <h:messages />
      <h:commandButton action="submit" value="Submit"/>
    </h:form>
  </f:view>
</body>

And here's the NalValidator class:

public class NalValidator implements Validator {

    public void validate(FacesContext facesContext, UIComponent uIComponent,
            Object value) throws ValidatorException {

        NAL enteredNal = (NAL)value;

        if (enteredNal.getName().equals("")) {
            FacesMessage message = new FacesMessage();
            message.setSummary("Name must be filled in!");
            message.setSeverity(FacesMessage.SEVERITY_ERROR);
            throw new ValidatorException(message);
        }
        
        if (enteredNal.getAddress1().equals("")) {
            FacesMessage message = new FacesMessage();
            message.setSummary("Address must be filled in!");
            message.setSeverity(FacesMessage.SEVERITY_ERROR);
            throw new ValidatorException(message);
        }

    }
   
}

If you're not familiar with JSF Validators, here's how you'd need to register the above, in the faces-config.xml file (lines 21-24 below):

<faces-config version="1.2" 
    xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
    http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd">
       
    <managed-bean>
        <managed-bean-name>NalBean</managed-bean-name>
        <managed-bean-class>nal.NalBean</managed-bean-class>
        <managed-bean-scope>application</managed-bean-scope>
    </managed-bean>
   
    <navigation-rule>
        <from-view-id>/welcomeJSF.jsp</from-view-id>
        <navigation-case>
            <from-outcome>submit</from-outcome>
            <to-view-id>/successJSF.jsp</to-view-id>
        </navigation-case>
    </navigation-rule>
   
    <validator>
        <validator-id>nal.NalValidator</validator-id>
        <validator-class>nal.NalValidator</validator-class>
    </validator>
 
</faces-config>

And then, when you redeploy, you'll have field-level validation for each input field for which you defined some kind of validation in your JSF Validator, as indicated below for the "Name" field:

Again, you require the 1.4 release of the NAL component (download it from here). That release includes the two attributes "required" and "requiredMessage", as well as the possibility of setting a custom validator as shown above. At this point, the only thing I am missing is an "id" attribute, which would be needed for setting the style of the message.

How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.

Topics:

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}