我們當(dāng)前使用的是 Vaadin Flow 版本 12.0.7（由于某些原因我們無(wú)法升級(jí)），并且我們希望覆蓋 ComboBox 組件的過(guò)濾機(jī)制。我的意思是，當(dāng)用戶(hù)在組合框內(nèi)輸入輸入時(shí)，我們希望更改組合框后面的項(xiàng)目的搜索方式。我正在查看Vaadin 文檔，了解如何實(shí)現(xiàn)組合框的自定義過(guò)濾。更具體地說(shuō)，該部分Filtering by a string看起來(lái)很有希望。根據(jù) Vaadin 文檔，我們實(shí)現(xiàn)了一個(gè)自定義接口來(lái)適應(yīng) ComboBox 的搜索方法：public interface CustomerDataFilter {? ? List<Customer> fetch(int offset, int limit, String filterText);? ? int getCount(String filterText);}這非常簡(jiǎn)單，并且與文檔示例幾乎 1:1 匹配。然后，我們根據(jù)文檔創(chuàng)建了一個(gè)方法，用數(shù)據(jù)填充 ComboBox。文檔中也幾乎使用了 1:1：private DataProvider<Customer, String>createDepartmentDataProvider(CustomerDataFilter service){? ?return DataProvider.fromFilteringCallbacks(query -> {? ? ? ?// getFilter returns Optional<String>? ? ? ?String filter = query.getFilter().orElse(null);? ? ? ?return service.fetch(query.getOffset(),? ? ? ? ? ? ? ?query.getLimit(), filter).stream();? ?}, query -> {? ? ? ?String filter = query.getFilter().orElse(null);? ? ? ?return service.getCount(filter);? ?});}我們?cè)诔跏蓟?ComboBox 的數(shù)據(jù)時(shí)調(diào)用上述方法。此時(shí)我們還實(shí)現(xiàn)了接口（盡管這可能很難看）。然而我們不太確定如何使用這兩個(gè)接口方法。我們的第一個(gè)目標(biāo)是始終返回所有項(xiàng)目并忽略任何特定過(guò)濾，這就是我們sorted始終返回整個(gè)列表的原因。這只是為了測(cè)試目的，嘗試我們是否更改了過(guò)濾。public void updateCustomerList() {? ? List<Customer> sorted = CustomerService.getInstance().findAll();? ? //for initial sorting? ? sorted.sort(new CustomerComperator());? ? DataProvider<Customer, String> test = createDepartmentDataProvider(new CustomerDataFilter() {? ? ? ? @Override? ? ? ? public int getCount(String filterText) {? ? ? ? ? ? return 0;? ? ? ? }? ? ? ? @Override? ? ? ? public List<Customer> fetch(int offset, int limit, String filterText) {? ? ? ? ? ? return sorted;? ? ? ? }? ? });? ? customerCompany.setItems(sorted);? ? customerCompany.setDataProvider(test);}我們嘗試將該getCount值增加到1，但一旦我們將其設(shè)置為高于0以下異常，就會(huì)發(fā)生：The number of items returned by the data provider exceeds the limit specified by the query (1).我們的猜測(cè)是，我們必須以某種方式調(diào)整getCount和fetch方法，以便它們實(shí)現(xiàn)我們的自定義搜索。這不會(huì)有問(wèn)題，因?yàn)槲覀冇?ComboBox 和filterText. 我們?cè)趺从悬c(diǎn)困惑為什么我們getCount還需要一個(gè)方法以及如何繞過(guò)顯示的異常？我們的想法是讓getCountalways 返回like10并fetch返回我們列表中sorted關(guān)于filterText.任何人都可以詳細(xì)說(shuō)明/幫助我們?nèi)绾螌?shí)現(xiàn)組合框的自定義過(guò)濾或?yàn)槲覀冎赋稣_的軌道嗎？
1 回答
阿波羅的戰(zhàn)車(chē)
TA貢獻(xiàn)1862條經(jīng)驗(yàn) 獲得超6個(gè)贊
您走在正確的軌道上，但您需要首先了解概念DataProvider。
在客戶(hù)端（瀏覽器），一旦用戶(hù)與其進(jìn)行交互，Vaadin 就會(huì)請(qǐng)求將數(shù)據(jù)顯示在組合框中。請(qǐng)求的數(shù)據(jù)類(lèi)似于“數(shù)據(jù)中有多少項(xiàng)？”?這是計(jì)數(shù)查詢(xún)。假設(shè)您有 100 件商品?，F(xiàn)在，下一個(gè)請(qǐng)求是“給我要顯示的前 40 個(gè)項(xiàng)目”，這是獲取查詢(xún)。組合框?qū)@示返回的項(xiàng)目。一旦用戶(hù)向下滾動(dòng)列表，就會(huì)發(fā)出另一個(gè)數(shù)據(jù)請(qǐng)求“給我接下來(lái)要顯示的 40 個(gè)項(xiàng)目”等。
總而言之，DataProvider首先要求返回所有項(xiàng)目的計(jì)數(shù)，然后根據(jù)需要逐頁(yè)獲取數(shù)據(jù)。當(dāng)用戶(hù)輸入過(guò)濾器時(shí)這也適用。不同之處在于您的計(jì)數(shù)和獲取查詢(xún)應(yīng)考慮過(guò)濾器。
示例：用戶(hù)輸入了過(guò)濾器“xyz”，現(xiàn)在只有 50 個(gè)項(xiàng)目與此過(guò)濾器匹配（通過(guò)名稱(chēng)或其他內(nèi)容），因此您將在 count 方法中返回 50，并且您的 fetch 方法應(yīng)該相應(yīng)地進(jìn)行過(guò)濾。
您遇到的異常只是指出您的 fetch 方法返回的項(xiàng)目多于 Vaadin 請(qǐng)求的項(xiàng)目（查詢(xún)參數(shù)中的“l(fā)imit”參數(shù)）。這是因?yàn)槟?dāng)前不處理偏移/限制。
您有兩種選擇來(lái)實(shí)施您的數(shù)據(jù)提供程序：
使用列表數(shù)據(jù)提供者
Vaadin 提供了for 列表ListDataProvider的實(shí)現(xiàn)DataProvider。分頁(yè)已經(jīng)在實(shí)現(xiàn)中完成了，你不必關(guān)心它。使用該filteringBy方法根據(jù)輸入的過(guò)濾文本過(guò)濾數(shù)據(jù)。
這種方式更容易，但不可擴(kuò)展。這意味著如果您有很多項(xiàng)目，您將消耗大量?jī)?nèi)存和 CPU，因?yàn)檎麄€(gè)數(shù)據(jù)都是從后端檢索到列表中的。如果您預(yù)計(jì)商品數(shù)量較少，請(qǐng)采用此方法。
或者實(shí)現(xiàn)您自己的 DataProvider
您可以實(shí)現(xiàn)自己的DataProvider.?我建議從擴(kuò)展AbstractBackendDataProvider類(lèi)（javadoc）開(kāi)始。方法sizeInBackend和fetchFromBackend需要實(shí)施。請(qǐng)注意在 fetch 方法中實(shí)現(xiàn)分頁(yè)的偏移/限制參數(shù)。
如果您將分頁(yè)委托給數(shù)據(jù)庫(kù)（例如 SQL 或 no-sql 數(shù)據(jù)庫(kù)），則此方法是可擴(kuò)展的。內(nèi)存占用會(huì)很低，因?yàn)槟辉趦?nèi)存中保留一頁(yè)。
添加回答
舉報(bào)
0/150
提交
取消