I’m just learning CUBA, and trying to implement a filter that takes a selected ‘root’ record ID from a user settings page and applies it automatically on all browse screens necessary where the entity is related to the “root entity”.
I have created an interface with a method that returns the join string (how to reach the root entity from current one) for the filter and is implemented by the entities where this filtering is necessary.
Then i created a FilterLookup class that extends StandardLookup.
In one of the lifecycle hooks or events i would like to apply the filter condition to the default filter visible on all browse screens, or achieve filtering of the datasource in any other way.
So in the end to use this feature one would only need to implement the join returning method on the entity, and extend my FilterLookup instead of StandardLookup when creating a new screen.
My problem is that accessing the filter control’s datasource throws a null pointer exception - i tried to apply the filter on it in Init, BeforeShow events and by overriding InitActions method.
What would be the best way to add a condition automatically to the filter?
Applying the filter condition directly on the backend would be even better but i don’t know how to access the datasource of descendant lookup screens in a generic way.
Or maybe my approach is flawed, and this should be implemented in an entirely different way?
I will provide some alternatives, but these alternatives viability depends on your usage context (wich I don’t know of).
1 - If this “root entity” filter must always be applied (i.e., users should not be able to change its value), then I would suggest you to use Constraints.
2 - Another approach that you can use is to create a “custom condition”. I used cuba-petclinic demo to create some sort of “My pets” filter.
I changed one of the owners’ email, so that I could filter the pets belonging to one owner only - the one who has the same e-mail as the logged user:
3 - The last approach (and the most complicated one) is to set filter value Programatically in the screen controller. Take a look at this topic, it will help you to figure it out how to implement this approach (sadly, changing generic filter values is not well documented and you will need to use XML).
Thanks @peterson.br !
The filter values can be changed any time, just 2 combo boxes that are always visible in the app.
It’s a convenience feature for quick filtering.
I found a solution, though i don’t know how viable it is.
I got the DataLoaders through the ScreenData property of the screen, there i found the actual query.
I applied the JpqlCondition(s) to all the loaders’ queries if their entity implements any of the filtering interfaces. So far no events (filtering, refresh) change or reset that query, but the 3. solution sounds more “official” then what i do.
