I had a post about the solution to suppress ADF LOV Like operator and prevent LOV popup loading when user is typing existing value - Suppressing ADF LOV Like Operator Filtering. Thanks to a blog reader, there was one use case found, when Like operator was not suppressed properly. This is fixed now and I would like to post updated sample application here.
Additional method is overridden in LOV VO implementation class - applyViewCriteria(ViewCriteria, boolean). Besides previously overridden method buildViewCriteriaClauses(ViewCriteria), this method provides additional handling for LOV Like operator suppression. Download sample application - ADFTableApp_v2.zip.
Blog reader reported an issue, when LOV value was changed to 10, again changed to 100 and again 10, then LOV popup was opened on the last change. This should not happen, as value 10 exists in the LOV. It seems like when LOV value is changed to the same as it was set before, ADF BC executes extra call for LOV filter through applyViewCriteria method. This is why this method is overridden as well as buildViewCriteriaClauses.
Both methods are overridden and check for STARTSWITH (Like) operator is implemented:
It works well now. Try to enter value 10, LOV will accept this value without opening LOV popup:
Enter value 100, this value will be accepted as it exists in the LOV list:
Again enter value 10, it will be accepted as it was previously (it will not be, without overriding applyViewCriteria method):
If I type any value, not available in the LOV list:
As expected LOV popup will be opened and user could select a valid value:
Additional method is overridden in LOV VO implementation class - applyViewCriteria(ViewCriteria, boolean). Besides previously overridden method buildViewCriteriaClauses(ViewCriteria), this method provides additional handling for LOV Like operator suppression. Download sample application - ADFTableApp_v2.zip.
Blog reader reported an issue, when LOV value was changed to 10, again changed to 100 and again 10, then LOV popup was opened on the last change. This should not happen, as value 10 exists in the LOV. It seems like when LOV value is changed to the same as it was set before, ADF BC executes extra call for LOV filter through applyViewCriteria method. This is why this method is overridden as well as buildViewCriteriaClauses.
Both methods are overridden and check for STARTSWITH (Like) operator is implemented:
It works well now. Try to enter value 10, LOV will accept this value without opening LOV popup:
Enter value 100, this value will be accepted as it exists in the LOV list:
Again enter value 10, it will be accepted as it was previously (it will not be, without overriding applyViewCriteria method):
If I type any value, not available in the LOV list:
As expected LOV popup will be opened and user could select a valid value:
3 comments:
Hi Andrejus,
Thank you for sharing your solution. It works great.
However, if I apply your solution to an LOV that has autosuggest, the autosuggest no longer work because it is using the same view criteria item that is now changed to "=". In my application, autosuggest is dynamically added to the LOV. It means that the method ViewObjectImpl.buildViewCriteriaClauses(ViewCriteria) is called for LOVs with or without autosuggest.
How do I make your solution work with autosuggest added to the LOV?
In the method ViewObjectImpl.buildViewCriteriaClauses(ViewCriteria), can we detect if it is called for autosuggest?
Thank you
JP
Hi,
I would need to test with auto suggest, this wasn't a requirement before. I will put on my todo list.
Regards,
Andrejus
Thumbs Up!
Post a Comment