Search Expressions since 0.8.0

Inspired by PrimeFaces, BootsFaces implements a couple of powerful search expressions to make your life easier. In almost every case, you can get rid of ids. Use @form, @next,@previous,@parent and even jQuery-Expressions like @(.css-class) instead.

State of the art

The search expressions can be used with the update and process attributes of the AJAX-enabled BootsFaces components. For these components, the search expressions should also work with traditional <f:ajax /> facets (although we discourage the use of these AJAX facets - in most cases you don't need them).

Basic usage

Like in standard JSF, you can use ids to determine which region of the DOM to update:

The preceding colon indicates that :tabViewId isn't inside the "naming container" - usually a form or a custom composite component - but in the root of the JSF component tree. The panelId is direct descendant of the form, so it doesn't need a colon.

Standard JSF search expressions

Standard JSF introduces several search expressions, basically shortcut allowing you to get rid of the ids in many cases:

PrimeFaces search expressions supported by BootsFaces

PrimeFaces adds a couple of very useful search expressions, which are supported by BootsFaces, too. (Actually, @next and @previous originally were contributed to PrimeFaces by one of the BootsFaces team members):

BootsFaces search expressions

BootsFaces introduces several search expressions, basically shortcuts allowing you to get rid of the ids in many cases. Note that most BootsFaces search expression scan the entire JSF tree recursively, which may result in a performance penalty. If that's an issue, you can optimize the performance by limiting the search to a subtree. For instance, @property("myBean.myProperty") scans the entire JSF tree, while @form:@property("myBean.myProperty") limits the search to the current form.

PrimeFaces search expressions BootsFaces does not support

There are a few PrimeFaces search expressions BootsFaces does not support:

Classical use cases

The reason why one of us (Stephan) originally invented @next and @previous was that he'd observed that input fields typically occur as a triplet: a label, the input field itself and an error message. It's rather cumbersome and error-prone to implement this using ids, but it's pretty straightforward with @next and @previous. As a bonus, you can copy and paste input field much more easily, and you can even move them from one form to another without updating the id. In fact, the only reason why the example below uses ids is because you need to knwo the id in order to create messages on the server side.

Live preview

@after comes in handy if you've got a complex form. Let's add a switch to the previous example. The input field is hidden until the switch is activated. Of course, both the label and the error message have to be hidden, too. You can achieve this with update="@after":

Live preview

However, this example also shows that the validation logic of JSF usually gets in your way when you try to hide or show fields depending on other fields. Better use JavaScript instead.

More advanced live demo

This demo shows some of the options at a glance.

Live preview

All-in-One-Demo (aka cheat sheet)

This demo shows most options on a single screen. Most buttons modify the images. The buttons in the image row modify the image in the same row. The buttons below modify the entire page. Some buttons also show the appearance of the button itself (by counting up the numbers). As you can see, you can freely combine every option the search expression framework gives you.

Live preview