My JSF Books/Videos My JSF Tutorials OmniFaces/JSF PPTs
JSF 2.3 Tutorial
JSF Caching Tutorial
JSF Navigation Tutorial
JSF Scopes Tutorial
JSF Page Author Beginner's Guide
OmniFaces 2.3 Tutorial Examples
OmniFaces 2.2 Tutorial Examples
JSF Events Tutorial
OmniFaces Callbacks Usages
JSF State Tutorial
JSF and Design Patterns
JSF 2.3 New Features (2.3-m04)
Introduction to OmniFaces
25+ Reasons to use OmniFaces in JSF
OmniFaces Validators
OmniFaces Converters
JSF Design Patterns
Mastering OmniFaces
Reusable and less-verbose JSF code

My JSF Resources ...

Java EE Guardian
Member of JCG Program
Member MVB DZone
Blog curated on ZEEF
OmniFaces is an utility library for JSF, including PrimeFaces, RichFaces, ICEfaces ...

.

.

.

.

.

.

.

.


[OmniFaces Utilities] - Find the right JSF OmniFaces 2 utilities methods/functions

Search on blog

Petition by Java EE Guardians

Twitter

luni, 7 noiembrie 2016

JSF 2.3 comes with @ManagedProperty compatible with CDI

The JSF managed bean annotations will be deprecated in JSF 2.3. This includes @ManagedProperty as well. But, compared to other annotations, this one has got an implementation that can be used with CDI managed beans. So, in CDI managed beans we can use the new, javax.faces.annotation.ManagedProperty. Let's see an example of injecting an instance of SourceBean into TargetBean, and a property of SourceBean into TargetBean:

@Named
@RequestScoped
public class SourceBean {

 private String source;
   
 @PostConstruct
 public void init(){
  source = "SourceBean";
 }

 public String getSource() {
  return source;
 }

 public void setSource(String source) {
  this.source = source;
 }       
}

import javax.faces.annotation.ManagedProperty;
...
@Named
@RequestScoped
public class TargetBean {

 @Inject @ManagedProperty("#{sourceBean}")
 private SourceBean sourceBean;
   
 @Inject @ManagedProperty("#{sourceBean.source}")
 private String source;
   
 public void targetAction(){
  System.out.println("Injected bean: " + sourceBean);
  System.out.println("Injected property (via injected bean): " + sourceBean.getSource());
  System.out.println("Injected property: " + source);
 }
}

The complete example is available here.

duminică, 6 noiembrie 2016

duminică, 31 iulie 2016

[OmniFaces utilities (2.4)] Format the given number to nearest 10^n (rounded to thousands)


[OmniFaces utilities] The formatThousands() formats the given number to nearest 10n (rounded to thousands), immediately suffixed (without space) with metric unit (k, M, G, T, P or E), rounding half up with a precision of 3 digits, whereafter trailing zeroes in fraction part are stripped. Numbers lower than thousand are not affected. The format locale will be set to the one as obtained by Faces#getLocale(). If the value is null, NaN or infinity, then this will return null.

This function is available from OmniFaces 2.3, but in OmniFaces 2.4, the incorrectly trimmed trailing zeroes from non-fractional integer numbers was fixed and now also supports cutting down fractions of values lower than thousand.

Function:

Usage:

// 9.99 k
#{of:formatThousandsUnit(9994)}
      
// 10 M
#{of:formatThousandsUnit(9995000)}

// 532 k
#{of:formatThousandsUnit(532230.6483)}

sâmbătă, 23 iulie 2016

[OmniFaces utilities (2.4)] Format the given number to nearest 10^n, suffixed with a space, the metric unit prefix and the given unit


[OmniFaces utilities] The formatThousandsUnit() formats the given number to nearest 10n (rounded to thousands), suffixed with a space, the metric unit prefix (k, M, G, T, P or E) and the given unit, rounding half up with a precision of 3 digits, whereafter trailing zeroes in fraction part are stripped. The format locale will be set to the one as obtained by Faces#getLocale(). If the value is null, NaN or infinity, then this will return null.The given unit used in the format is of type B for Bytes, W for Watt, etc. If the unit is null, then this method will behave exactly as described in #formatThousands(Number).

This function is available from OmniFaces 2.3, but in OmniFaces 2.4, the incorrectly trimmed trailing zeroes from non-fractional integer numbers was fixed and now also supports cutting down fractions of values lower than thousand.

Function:

Usage:

// 9.99 kB
#{of:formatThousandsUnit(9994  , "B")}
      
// 10 MW
#{of:formatThousandsUnit(9995000 , "W")}
 
// 532 kFOO
#{of:formatThousandsUnit(532230.6483 , "FOO")}

duminică, 17 iulie 2016

[OmniFaces utilities (2.4)] Get all request query string or view parameters appended with all child UIParameter components of the given parent component


[OmniFaces utilities] The getParams() returns an unmodifiable map with all request query string or view parameters, appended with all child UIParameter components (<f|o:param>) of the given parent component. Those with disabled=true or an empty name or an empty value are skipped. The <f|o:param> will override any included view or request parameters on the same name.

Method:
Usage:

Let's suppose that we have the following page:

<f:metadata>
 <f:viewParam name="playernameparam" value="#{playersBean.playerName}"/>           
 <f:viewParam name="playersurnameparam" value="#{playersBean.playerSurname}"/>
</f:metadata>
<h:head>
 <title></title>
</h:head>  
<h:body>    
 <h:panelGrid columns="2">
  <h:form id="form">
   <h:commandButton id="submit" value="Get all params" action="#{playersBean.allParams()}">   
    <f:param name="ageParam" value="29"/>
    <o:param name="playParam" value="left"/>
   </h:commandButton>
  </h:form>                 
 </h:panelGrid>
</h:body>

Further, we can use the Components#getParams() utility to programmatically collect the UIParameters  (<f|o:param/>) nested in the above <h:commandButton/> and the view parameters. This can be accomplish in different JSF artifacts; for example, in a bean (obviously, there are several ways to identify the parent UIComponent of the UIParameters that we want to collect - the UIComponent that should be passed to the #getParams() should be obtained in a convenient manner depending on your circumstances; below, we simply used the Components#findComponent() utility):

import org.omnifaces.util.Components;
...
public void allParams() {
              
 UIComponent uc = Components.findComponent("form:submit");
 Map<String, List<String>> paramsMap = Components.getParams(uc, false, true);

 for (Map.Entry<String, List<String>> entry : paramsMap.entrySet()) {
      System.out.println("Param: "+ entry.getKey() + "/" + entry.getValue());
 }
}

Let's suppose that we start the application with an URL like this:

http://myapp/?playernameparam=rafael&playersurnameparam=nadal

After we press the Get all params button the server log will reveal the following output:

Param: playernameparam/[rafael]
Param: playersurnameparam/[nadal]
Param: ageParam/[29]
Param: playParam/[left]

sâmbătă, 9 iulie 2016

[OmniFaces utilities (2.4)] Get the HTTP request URL with query string, regardless of any forward


[OmniFaces utilities] The getRequestURL() method returns the HTTP request URL with query string, regardless of any forward. This is the full request URL without query string as the enduser sees in browser address bar.

Method:

Usage:

import org.omnifaces.util.Servlets;
...
@WebServlet("/MyServlet")
public class MyServlet extends HttpServlet {
 protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
  // e.g. http://localhost:8080/MyApp/MyServlet
  String req = Servlets.getRequestURL(request);
 }
 ...
}

miercuri, 6 iulie 2016

[OmniFaces utilities (2.4)] Get the HTTP request query string, regardless of any forward


[OmniFaces utilities] The getRequestQueryString() method returns the HTTP request query string, regardless of any forward.

Method:
Use this one outside JSF context
(Servlets#getRequestQueryString())
See also: Utils.coalesce()
Use this one in JSF context
(Faces#getRequestQueryString())
See also:  Faces.getRequest() | Faces.getContext()
Usage:

Some use cases are available right in OmniFaces source code. For example, OmniFaces uses getRequestQueryString() to get the HTTP request URI with query string, regardless of any forward:

public static String getRequestURIWithQueryString(HttpServletRequest request) {
 String requestURI = getRequestURI(request);
 String queryString = getRequestQueryString(request);
 return (queryString == null) ? requestURI : (requestURI + "?" + queryString);
}

luni, 4 iulie 2016

[OmniFaces utilities (2.4)] Get the HTTP request URI, regardless of any forward or error dispatch


[OmniFaces utilities] The getRequestURI() method returns the HTTP request URI, regardless of any forward or error dispatch. This is the part after the domain in the request URL, including the leading slash.

Method:
Use this one in JSF context
(Faces#getRequestURI())
See also:  Faces.getRequest()  Faces.getContext()
Use this one outside JSF context
(Servlets#getRequestURI())
See also: Utils.coalesce()
                              
Usage:

Some use cases are available right in OmniFaces source code. For example, OmniFaces uses getRequestURI() to check if the given HTTP servlet request is a JSF resource request:

public static boolean isFacesResourceRequest(HttpServletRequest request) {
 return getRequestURI(request).startsWith(request.getContextPath() + ResourceHandler.RESOURCE_IDENTIFIER + "/");
}


public static String getRequestURIWithQueryString(HttpServletRequest request) {
 String requestURI = getRequestURI(request);
 String queryString = getRequestQueryString(request);
 return (queryString == null) ? requestURI : (requestURI + "?" + queryString);
}

duminică, 3 iulie 2016

[OmniFaces utilities (2.4)] Get a list of all action expressions and listeners associated with given component


[OmniFaces utilities] The getActionExpressionsAndListeners() method returns a list of all action expressions and listeners associated with given component. This covers expressions in action attribute of command components and listener attribute of ajax components. Any method expressions are in format #{bean.method} and any action listeners are added as fully qualified class names. This list is primarily useful for logging postback actions in a phase listener. You can use #getCurrentActionSource() to obtain the current action source.

Method:

Usage:

Let's suppose the following code:

<h:form>
 <h:commandButton value="Foo" actionListener="#{fooBean.fooActionListener()}" action="#{fooBean.fooAction()}">
  <f:setPropertyActionListener id="foo" target="#{fooBean.foo}" value="Foo"/>                              
  <f:ajax execute="@form" render="@form" listener="#{fooBean.ajaxFooListener()}"/>
 </h:commandButton>
</h:form>

Now, programmatically (for example in a phase listener) we can do this:

import org.omnifaces.util.Components;
...
// use getCurrentActionSource() to get the source of the currently invoked action
UIComponent command = Components.getCurrentActionSource();
List<String> ael = Components.getActionExpressionsAndListeners(command);

// or, use getCurrentCommand() to get the currently invoked UI command component
UIComponent command = Components.getCurrentCommand();
List<String> ael = Components.getActionExpressionsAndListeners(command);

Both examples will return a List<String>  that contains the following items:

[
 #{fooBean.fooAction()},
 javax.faces.event.MethodExpressionActionListener,  
 com.sun.faces.facelets.tag.jsf.core.SetPropertyActionListenerHandler$SetPropertyListener,
 #{fooBean.ajaxFooListener()}
]

[OmniFaces utilities (2.4)] Get the source of the currently invoked action


[OmniFaces utilities] The getCurrentActionSource() method returns the source of the currently invoked action, or null if there is none, which may happen when the current request is not a postback request at all, or when the view has been changed by for example a successful navigation. If the latter is the case, you'd better invoke this method before navigation.

Method:
Usage:

import org.omnifaces.util.Components;
...
UIComponent action = Components.getCurrentActionSource();

You can see several examples of using this method as:

- check whether the given component has invoked the form submit (hasInvokedSubmit()):

public static boolean hasInvokedSubmit(UIComponent component) {
 UIComponent source = getCurrentActionSource();
 return source != null && source.equals(component);
}

- get the currently invoked UI command component (getCurrentCommand()):

public static UICommand getCurrentCommand() {
 UIComponent source = getCurrentActionSource();
 return source instanceof UICommand ? (UICommand) source : null;
}

marți, 28 iunie 2016

CDI-JSF: Beans discovery modes

When we write applications that involves CDI we need to activate CDI by adding in our project a file named beans.xml. Usually, this file will look like below:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
 bean-discovery-mode="all">       
</beans>

In this post, we are interested in the part highlighted in red. If you never notice that part before, then this quick post is for you. Let's see what is happening when we have bean-discovery-mode="all", and for this let's consider a simple interface with two implementations, as follows:

public interface IFoo {
 public void fooSlaveAction();
}

@RequestScoped
public class FooImplAnnotated implements IFoo {

 private static final Logger LOG = Logger.getLogger(FooImplAnnotated.class.getName());  
   
 @Override
 public void fooSlaveAction() {
  LOG.info("FooImplAnnotated#fooSlaveAction() invoked ...");
 }   
}

public class FooImplNoAnnotation implements IFoo {

 private static final Logger LOG = Logger.getLogger(FooImplNoAnnotation.class.getName());  
  
 @Override
 public void fooSlaveAction() {
  LOG.info("FooImplNoAnnotation#fooSlaveAction() was invoked ...");
 }   
}

As you can see, the main difference between these two implementations consist in the fact that FooImplAnnotated is annotated with a CDI annotation, @RequestScoped. Well, now let's inject these two implementation in a third CDI bean:

@Named
@RequestScoped
public class FooBean {
   
 // inject the annotated bean
 @Inject
 private FooImplAnnotated fooAnnotated;        
   
 // inject the no-annotation bean
 @Inject
 private FooImplNoAnnotation fooNoAnnotation;
   
 public void fooMasterAction(){
  // call fooSlaveAction() of the annotated bean
  fooAnnotated.fooSlaveAction();
    
  // call fooSlaveAction() of the no annotation bean
  fooNoAnnotation.fooSlaveAction();
 }   
}

If we test this application (for example by calling the fooMasterAction() method  via a simple EL as #{fooBean.fooMasterAction()}), we will get the following messages  in the server log:

FooImplAnnotated#fooSlaveAction() invoked ...
FooImplNoAnnotation#fooSlaveAction() was invoked ...

Ok, this is the effect of using bean-discovery-mode="all" who tells CDI to discover all beans. No, let's alter the beans.xml as switch the value of bean-discovery-mode from all to annotated:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
 bean-discovery-mode="annotated">       
</beans>

This time the test will fail with an error of type org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type FooImplNoAnnotation with qualifiers @Default. Well, the problem is that the FooImplNoAnnotation is not discoverable and it cannot be injected in FooBean. Since we are looking only for annotated implementation, we can re-write our FooBean like below:

@Named
@RequestScoped
public class FooBean {

 // inject the annotated bean
 @Inject
 private IFoo fooAnnotated;

 public void fooMasterAction() {
  // call fooSlaveAction() of the annotated bean
  fooAnnotated.fooSlaveAction();
 }
}

Now, the test will pass again, and the server log will reveal this message: FooImplAnnotated#fooSlaveAction() invoked ...Since the FooImplNoAnnotation is not discoverable, CDI has choose  the single available implementation, FooImplAnnotated. Of course, if we make the FooImplNoAnnotation discoverable by adding a CDI annotation to it, then CDI will cause  ambiguous dependencies errors.

Ok, finally, let's switch the value of bean-discovery-mode from annotated to none:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
 bean-discovery-mode="none">       
</beans>

This time the test will not cause any error and no messages will be available in the server log. We just told CDI to not try to discover any bean.

The complete example is available here.

[OmniFaces utilities (2.4)] Create a copy of the array with items in reversed order


[OmniFaces utilities] The reverseArray() function returns a copy of the array with items in reversed order.

Function:
Usage:

Let's suppose that we have the following simple array defined in a bean:

@Named
@RequestScoped
public class MonthsBean {
   
 private String[] months = new String[] {"January", "February", "March", "April", "May", "June", "July", 
   "August", "September", "October", "November", "December"};

 public String[] getMonths() {
  return months;
 }           
}

Now, we can display the array as it was defined and in reverse order as below:

// as it was defined
<ui:repeat value="#{monthsBean.months}" var="item" varStatus="loop">
 #{loop.index + 1} : #{item} #{!loop.last ? ', ' : ''}
</ui:repeat>

Output:
1 : January , 2 : February , 3 : March , 4 : April , 5 : May , 6 : June , 
7 : July , 8 : August , 9 : September , 10 : October , 11 : November , 12 : December

// reversed (xmlns:of="http://omnifaces.org/functions")
<ui:repeat value="#{of:reverseArray(monthsBean.months)}" var="item" varStatus="loop">
 #{loop.index + 1} : #{item} #{!loop.last ? ', ' : ''}
</ui:repeat>

Output:
1 : December , 2 : November , 3 : October , 4 : September , 5 : August , 6 : July , 
7 : June , 8 : May , 9 : April , 10 : March , 11 : February , 12 : January

JSF BOOKS COLLECTION

Postări populare

Visitors Starting 4 September 2015

Locations of Site Visitors