CUBA Platform Filters — the Fast Food of Business Software?

DZone 's Guide to

CUBA Platform Filters — the Fast Food of Business Software?

How to use the filters on the CUBA Platform for enterprise Java app development.

· Java Zone ·
Free Resource

Last time I wrote about the generic filter and its opportunities that the CUBA Platform provides out of the box. I left off with two requirements which are important for developers, because they have to be 100% sure that the generic solution does not fall down with real world problems.

Going From Fast Food to a Real Healthy Meal

After going through the CUBA filter opportunities for the first time, it felt a little strange to me. The first thing I thought, was something like “OK, so WTF did I spent my time on the last few years?”. Because, at first glance, it seemed too good to be true. Don’t need to write this simple, boring and similar filter mechanisms by yourself anymore?

  • All orders that are in state X
  • All products that are in category Y
  • All orders that have been placed between t0 and t1
  • Yadda yadda yadda... 

From the developer's point of view this is just boring stuff. As you get to the schema behind it, it becomes pointless. Nevertheless, to wrap this generic schema into code that is efficient in terms of SQL statements and slick from a UX perspective is actually pretty hard. This is why oftentimes a developer, such as myself, does not go from the specific problem to a more general implementation that can then be used instead of developed.

Going back to the solution we have at hand from the last blog post. After first attempts to do some stuff with the filtering mechanism, I wasn’t aware what to make of it. At this point it feels a little like fast food.

Mostly fast to get, low price, and tasty to eat at the exact moment, but after eating it, you often have a queasy conscience. You probably have a feeling that it might hurt you in the long run.

The question basically is: Is this a healthy, well-tasting meal? Meaning: Are you on the right track with this solution, or will this tool fall off after the first non-obvious filter problems?

To it figure out I will go through the two objections from the last blog post.

1. Pre-defined Filter Combinations on Behalf of the User

Many times there is a need for a developer to pre-define filter possibilities. CUBA allows you to solve this problem on different layers. You can think of it as different categories in terms of intervene through the user as well as the developer. Below you’ll see a diagram that shows this classification.

Image title

So let’s look at the different layers one by one, starting with pre-defined generic filters.

1.1 Pre-defined Generic Filters

The first option that CUBA gives the user is an ad-hoc filter (like created in the previous blog post). It can be saved within the application. To do this, the Filter section has a little config icon on the right, that lets the user to choose between different options to save an ad-hoc filter.

Image title

With Save / Save as only filter conditions (not the given values), will be saved for the current user. Next, there is a possibility to save a filter as a Search folder. In this case, the entry will be shown in the side panel of the application. It stores the conditions as well as the input values and can be shared with other users. There is more stuff like Sets, which will let you save the results insted of the filter definition.

I’ve just screached the surface of the different options — more information about the abilities can be found here.

1.2 Custom UI With Generic Filters

The options that I showed above are mostly the same from a UI perspective. Oftentimes the need for a pre-defined filter comes from the wish to let a user to be more efficient in filter execution. If you want to give the user this productiviy improvment, a custom filter UI can be created.

Image title

When you go through the example app, especially in the administration section of the app, you’ll find different platform screens, where the generic filter solution is replaced with a custom filter UI. Above you'll see an example of the Entity Log view.

As you can probably imagine, there are no limits in the customization of the UI. You can use all available input elements as well as layout containers to design a perfect UI.

Alongside with the customization of the UI elements, it comes the burden to handle UI events that apply the filter on your own. This is basically the trade-off you have to make to implement this kind of UI.

1.3 Programatically Filtered Datasources

The third option that you have is to adjust the underlying datasource of the filter. Generally, a datasource is a concept that is responsible for data provided to the UI components. Of course, you have programatic access to these datasources, but oftentimes it is totally OK to just configure these datasources through the declarative definition in the XML descriptor. An example of this definition you’ll find in the product-browse view in the ordermanagement app:

    <collectionDatasource id="productsDs"
            <![CDATA[select e from om$Product e]]>

In the query tag you can change the query string that should be executed. As this is a plain old JPQL Query, there is obviously a lot of freedom. A few examples can be found in the docs.

2. Support for Complex Filters Beyond Attribute Values or Related Entities

The second objection that I brought up last time is the question about the support for filters that go beyond “simple” attribute based filterings. That might be even more important than the previous topic.

So, let’s have a look about what CUBA is capable of in this regard. Since it’s a little bit harder to categorize these advanced filter requirements, I’ll go through a few examples that should give an overview of what is possible out of the box.

Products That Have Been Created Within the Last Week

The first example that shows the dynamism of the filter feature is the possibility to add a custom condition. We’ll define this condition with a criteria that uses a JQPL macro.

Lets assume we want to filter for all products, that have created within the last week. We want to track the success of this products through the orders to do a marketing campaign if necessary.

First of all, we create a new condition via the UI (Product browser > Add search condition > Create new… ). The name can be something like “from last week”.

Image title

In the Where condition we’ll use the JPQL macro @between to define that createdTs has to be in the time frame (now-5) and now. {E} is the current entity (in this case Product).

Give Me All the iPhone Lovers

The next filter example is based on an 1:N relationship. In this case, we want all the orders, that contain at least one iPhone in it. This is a little more advanced, because the product information are stored in the LineItem entity, not in Order directly.

The object graph displayed as a wonderful train wreck and goes like this:


To get this up and running, lets go into the Orders browse view:

Image title

You’ll find the orders in the example app. The second one, 15/11/2015 from Misty contains a line item with an iPhone as the product.

Next, we create another new search condition with the following settings:

Image title

In the Join Attribute, we will join the line items relation in the query. Next, in the where attribute, we tell CUBA that li (the current Line Item) should have a product, which has a name that is like ‘%iPhone%’.

This is basically it. When doing the search (and choose the checkbox above the search button to activate the condition), you’ll get only Misty’s order.

It’s a Bit Over, Is That OK?

A tiny little extension will drastically increase the value of this filter. Instead of pre-defining the search string, you can let the user decide what product names to search for. Changing the where attribute to the following:

li.product.name like ?

As well as setting the parameter type to “String” instead of “No Parameter” will give you a input field in the filter section. Entering “iPhone” or “8810” will give the the first or the corresponding second order.

Using the parameter feature a little more, we could extend our query to search for all orders that have a product in the category that the user wants to:

Image title

I could go on and on with the examples of “advanced” filters, but I think you've already chaught the point. I haven’t covered all available possibilites, but it’s up to you to find it out.

The bottom line of this second objection is, that the limit is not at the point you might think of after reading my last blog post. Instead it is broader and includes much more filter use cases.

If You Think it’s Fast Food, At Least it’s Delicious

If we really want to stick to the fast food analogy (and I do want, you can be sure), let's say it's like Jules Winfield in Pulp Fiction did:

Mmm, this is a tasty burger!

It’s not this McDonalds or Burger King kind of fast food. Its not just any fast food restaurant. At least the CUBA filters are a very tasty Burger from Big Kahuna Burger.

First of all, CUBA generic filters are fast (to “develop”). That’s fact. If you compare it to developing the same feature set from scratch — well, we’ll see us in a year (if you have your five programming buddies around), even if you plan to implement the concrete filter requirements you have at hand. Compare the effort to using this solution: even in this case it will be more effort.

Second, CUBA generic filters are cheap. Since software developers paychecks are the driving cost factors in most IT efforts, you should probably optimize it. I will not start make or buy discussion right here, but i think the price to performance ratio is pretty unique. Perhaps I’ll cover this topic in a future blog post.

Last but not least, CUBA generic filters are healthier than their reputation (or the one that I painted above). I hope I could point out that unlike our burger example here, the filter mechanism is not just for the run-of-the-mill case. Instead it can handle filter requirements that are way beyond what anyone could call “easy”.

cuba, enterprise, filter data, java

Published at DZone with permission of Mario David . See the original article here.

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}