表達式語言bean屬性評價順序

鑑於託管bean（爲myBean），其延伸一個抽象類（AbstractMapModel），其本質上是一個地圖的包裝：表達式語言bean屬性評價順序

的AbstractMapModel類包括的getValue（對象key）方法。

MyBean類包含一個getName（）方法。

XPage的值爲＃{MyBean.name}。

我發現它調用MyBean.getValue（「Name」）並忽略MyBean.getName（）。我的問題是，這是正確的操作？

邏輯上，它似乎應該在嘗試廣義getValue（「Name」）之前嘗試更具體的getName（）。做一些研究，看起來如果getValue（）返回null，它應該尋找一個特定的getter，即使我發現邏輯可疑，至少會得到正確的最終結果。但是，兩者都沒有發生。

我已經解決了這個問題，下面的代碼：

public Object getValue(final Object key) { 
    /* Following code added to check for specific getter before performing getValues() */ 
    String propertyName = key.toString(); 
    propertyName = propertyName.substring(0, 1).toUpperCase() + propertyName.substring(1); 
    Method method = null; 
    try { 
     method = this.getClass().getMethod("get" + propertyName, new Class[] {}); 
     if (method != null) { 
      return method.invoke(this); 
     } 
    } catch (Exception e) { 
     // Do nothing 
    } 
    try { 
     method = this.getClass().getMethod("is" + propertyName, new Class[] {}); 
     if (method != null) { 
      return method.invoke(this); 
     } 
    } catch (Exception e) { 

    } 
    /* --------------------------------------------- */ 
    return getValues().get(key); 
}

它似乎並不喜歡這個解決辦法應該是必要的，所以我不知道如果我有什麼事情的一些基本誤解。或者，我應該做些什麼更好的方法？

來源

2016-04-14 Gary Forbis

我很久沒見過它了，但Tim Tripcony爲NotesIn9做了一個關於這個的視頻，並且如果我沒有記錯的話就會談到這個確切的問題。基本上Tim提出的是最好的解決方案。 –

我正在做的是來自Tim的工作。我有一段時間沒有回顧過NI9，我想我只記得這是如何工作的。謝謝！ –

儘管它通常很有用，但EL並沒有遵循這樣的「後備」策略。相反，它有一組接口，它循環 - Map,DataObject等（我不記得具體的順序） - 並且，如果對象匹配其中的一個，它將獨佔使用該路由。你在那裏做了什麼，反思，是我用來獲得這種行爲的相同策略。

來源

2016-04-14 17:50:51

假設你可以在列表的開始處註冊一個新的處理程序，它將採取任何對象並對其執行「後備」排序，但這樣做可能太值得冒險了。 –

我嘗試編寫最小的hackiness代碼，所以我認爲我會堅持使用這種方法。有沒有理由不這樣做，如表現不佳或什麼的？我試圖確定它是否屬於抽象類，或者如果我應該在個案基礎上重寫該行爲。我可以重寫我的getValue來查找特定的鍵，然後返回該方法而不是從地圖查找值。但是這段代碼看起來真的很難看。 –

沒有什麼太大的理由擔心反射性能，直到它變成一個實際的問題 - 反射與整體測試相比是「緩慢」，與任何數據庫相關的速度相比，速度非常快。我一直在使用這條路線，並且沒有必要三思。如果_does_證明速度太慢，那麼您的「檢查特定鍵」路徑就是要走的路 - 這就是IBM的對象，如DominoViewEntry所做的。 –

表達式語言bean屬性評價順序

回答

相關問題