Search Expression Framework

In JSF API, UIComponent#findComponent only accepts id expressions.
In the render/execute attribute of f:ajax, you can also reference components by some special keywords:

  • @this
  • @form
  • @parent
  • @all
  • @none

In PrimeFaces 3.x, we already improved the findComponent logic by adding some new features like @namingcontainer and PrimeFaces Selectors. PrimeFaces Selectors aka provides the ability to reference components by JQuery selectors e.g. (@(:input:disabled), @(.ui-datatable .ui-panel)).

For PrimeFaces 4.x, we have taken this to the next level. Thomas Andraschko completely over-worked our search expression logic and created a modular framework with new features and enhancements to resolve some problems.

New Keywords

  • @composite resolves the closest CompositeComponent parent
  • @widgetVar(name) resolves a component by its widgetVar
  • @child(index) resolves the nth child

Combinable keywords are also supported;

  • @form:@parent
  • @composite:myButton
  • @this:@parent:@parent
  • @form:@child(2)

Demo

Sample expressions demo is available at PrimeFaces Showcase.

Roadmap

This expressions can be used for all component in PrimeFaces, not only in the process and update attributes! Ajax, CommandButton, Watermark, Printer and many more!

Some components requires to resolve the UIComponent instance on the server side, so PFS and @widgetVar are not available for all attributes. These are considered as client side expressions only.

NOTE:

  • Client side expressions are also NOT safe as server side expressions.
  • If a server side expression can’t be resolved, we throw an exception.
  • If your selector is wrong, the component will just not be found.
This entry was posted in JSF. Bookmark the permalink.

7 thoughts on “Search Expression Framework

  1. Thanks to Thomas! He done a great job which we discussed last time due to several requirements. @composite is the most handy feature, I guess. Also chaining of search expressions is cool. Thomas told me that he also added “appendTo” to p:dialog. So, we can use now e.g. appendTo=”@(body)”.

  2. Interesting post. I need to try to use this new feature, and last but not least, I’m loving Thomas’s contributions and work on/for PrimeFaces!

    Keep up the good work, PrimeFaces Team, and keep coming with soooo many useful and new features! :)

  3. Great work from Thomas! He created soo many test cases to work out in all possible scenarios.@composite will be the key feature and no need to mention full chain path now.How about primefaces extensions component support? for example tooltip forSelector etc

    As per note “Client side expressions are also NOT safe as server side expressions.” Which one will provide optimized performance in JSF web applications?

  4. Sudheer, forSelector is useless now. We can just use: for=”@(#myId)” or similiar.

    I will migrate PrimeFacesExtensions end of august to 4.0.

    For performance… It really depends on the case.
    PFS doesn’t hurt the render time but evaluate it with JS on a post will be slow in slow browsers (IE8, …)
    I would go, if possible, with small relative expresions like: @parent:myInput

    It should have a good performance and is validated on server side.
    For special cases and high performance render time, you should go with PFS. If you use PFS in all cases, the JS execution time and post time will be slower.

    • One thing I’d like to add is data iteration, suppose you have a button inside a datatable that updates a dialog and shows the row data on complete. If you have n rows, update=”dialog” will run n times on server side, I prefer using PFS in this case for example.

    • Thank you Thomas!! So we can depricate/remove forSelector,forElement attributes in all components.Better to avoid big search expressions from PFS/Jquery selectors Since clients still preffered IE8 version.I used PFS only in few scenarios like updating selectOneMenu inside datatable(data iteration)