CUBA 7 新特性（上篇）
??
?
三年前，我們宣布了 CUBA 框架的第二個公開的主版本。CUBA 6?是改變游戲規則的版本 - 框架的許可從私有化變成了公開的 Apache2.0。那些日子里，我們甚至猜不到這個變化會最終將框架帶向何方。隨之而來的是，CUBA社區開始呈指數級增長，從中我們學習到許多開發人員可能使用框架的方法（有時甚至是不可能的方法）?，F在我們很高興的宣布 CUBA 7?的發布，通過這個版本，我們希望那些剛剛開始CUBA和Java之旅的社區成員能更加順利和快樂的成長為熟練的企業級開發人員或者Java專家。
?
開發工具
顯然，CUBA 的成功很大一部分要依賴于 CUBA Studio。它極大的簡化了繁瑣的 Java 企業級開發任務，很多地方被簡化成只需要在可視化編輯器進行簡單的配置即可，不需要了解Persistence API 或者 Gradle，甚至不需要了解 Spring 就能開發出來完整的、功能豐富的CRUD 應用程序。這一切，Studio就能幫你完成。
以前，Studio 是一個單獨的 web 應用程序，這樣會有一些明顯的局限：
l?首先，Studio 并不是功能完備的 IDE，所以開發者需要經常在 Studio 和 IntelliJ IDEA 或者Eclipse 之間切換，以便在 IDE 中開發業務邏輯，也能更好的利用 IDE 方便的導航、代碼完成功能和其他必要的功能。來回地切換有時候很煩人。
l?其次，Studio 的簡單性是建立在大量的源碼解析和生成的基礎上。所以，要提高代碼生成的能力也就意味著要朝著開發功能完備的IDE方向努力 - 這個想法太過雄心勃勃了。
最后我們決定依靠另一位巨人的肩膀來解決這些局限?，F在 Studio 跟 JetBrains 開發的IntelliJ IDEA 合并了?，F在可以將 Studio 作為 IntelliJ IDEA 的插件安裝或者下載單獨打包的版本。
?
這個方法為我們開辟了新的視野：
l?能支持其它JVM的開發語言（首先就是Kotlin）
l?提升了熱部署的能力
l?整個項目中能更直觀的導航
l?更聰明的代碼生成和提醒
現在新的Studio正在積極的開發中：我們正在移植舊版本的功能。短期計劃還包括使用原生IntelliJ UI重新實現基于 Web 的設計器，并改善項目導航體驗。
技術棧升級
跟以前主版本升級一樣，這次底層的技術棧也做了升級，比如 Java 8/11，Vaadin 8，Spring 5。
默認情況下新項目會使用Java 8，但是也可以通過在build.gradle中添加下面的內容來指定需要的Java版本：
?
升級到Vaadin 8是個不小的挑戰，因為Vaadin的數據綁定API發生了很大的破壞性變化。但使用CUBA的開發者很幸運，因為CUBA為開發者提供了統一封裝的自有API層，屏蔽了底層Vaadin的內部結構。CUBA開發團隊做了大量的工作，重新實現了很多內部邏輯以保持CUBA自有的API不變化。也就是說，這很好的保持了CUBA框架的兼容性，不需要做任何重構就可以直接移植到CUBA 7并享受Vaadin 8帶來的好處。
依賴庫的完整升級列表可以在官方的 release notes?中找到。
新的界面API
這一小節也可以稱為 “第一版界面API”，因為CUBA之前沒有任何官方的聲明在web客戶端層有API存在。界面API基于框架的歷史，也基于我們最初的一些假設：
以聲明為中心的方法 - 所有可以以聲明式描述的，都應該在界面描述文件中聲明，而不是在其控制器中編碼。
標準界面（瀏覽和編輯界面）提供具體的通用功能，一般不需要修改。
從最初的一千個成員加入了社區開始，我們就認識到對于“標準” CRUD 界面的需求是有多么廣泛，已經超出了最開始我們設計的一組功能了。然而，很長一段時間，即使沒有 API 層，我們也能夠處理自定義行為的需求，這是因為有另一個第一階段假設 - 開放繼承。有效地進行開放繼承意味著可以覆蓋基礎類的任何公共或保護方法，再根據需要定制其行為。這聽起來似乎是所有頑疾的解藥，但事實上可能短期都不一定能見效：如果被覆蓋的方法被重命名、刪除了或者將來版本的框架根本不同這個方法了，該怎么辦？
所以，為了響應社區日益增長的需求，我們決定引入新的界面API。API提供了清晰的長期的擴展點，而沒有隱藏的聲明式暗喻，靈活并且易于使用。
界面聲明
在 CUBA 7 里，界面聲明異常簡單：
?
從上面的例子我們可以看到，界面的標識符在控制器類上顯式的進行定義。也就是說，現在界面id和控制器類能相互唯一的對應。由此帶來的好消息就是，現在界面可以直接通過其控制類來安全訪問了（注意下面例子用控制器類來創建確認窗口）：
?
至此，界面描述文件不再是必須的，而成為了一個補充的部分。界面布局可以通過編程的方式創建或者通過 XML 界面描述聲明式創建，界面描述通過控制器類的 @UiDescriptor 注解定義。這樣能使得控制器和布局更加容易讀懂。這個方式跟Android開發中使用的模式非常類似。
之前，需要在web-screens.xml中注冊一個界面描述并為其設置一個標識符。在 CUBA 7 中，這個文件只是因為兼容性的考慮被保留下來，用新方法創建界面不需要這種注冊了。
界面生命周期
新的API帶來了清晰的自描述的界面生命周期事件：
l?Init
l?AfterInit
l?BeforeShow
l?AfterShow
l?BeforeClose
l?AfterClose
CUBA 7 中所有的界面相關的事件都可以用下面的方式訂閱：
?
將新API與舊方法進行比較，可以看到我們沒有重寫鉤子方法，之前這些鉤子方法在父類的層次結構中被模糊地調用?，F在我們在界面生命周期的明確預定義的點中定義業務邏輯。
事件處理和功能代理
前一小節我們介紹了如何訂閱生命周期事件，那么，其他組件呢？我們是否應該像在6.x版本中那樣在界面初始化時分散所有必需的監聽器？新API非常統一，因此訂閱其他事件與生命周期事件完全相似。
我們舉一個帶有兩個UI元素的簡單例子，一個按鈕和一個貨幣字段控件，因此它的XML描述符如下所示：
?
通過單擊按鈕我們調用中間件服務返回一個數字，該數字將被寫到貨幣控件中。貨幣控件需要根據價格的值更改其樣式。
?
在上面的例子中，我們看到有兩個事件處理器：一個是按鈕按下時調用的，另一個是當貨幣控件的值發生變化時執行的。就是這么簡單。
現在，我們設想一下，如果需要驗證價格的值并確保其為一個正數。最直接的方法就是在界面初始化的時候為其添加一個驗證器：
?
在真實的應用程序中，界面的入口點經常會被這種界面元素的初始化方法填滿。為了避免這個問題，CUBA提供了一個非常有用的注解 @Install?？纯词褂眠@個注解怎么避免這個情況：
事實上，這里是將貨幣控件驗證的邏輯代理給了界面的 currencyFieldValidator 方法來執行。雖然看上去稍微復雜一點，但是開發人員使用起這個功能來驚人的快速。
界面Builders/通知消息/對話框
CUBA 7 還引入了一些新的非常有用的帶有流式 API 的組件：
l?ScreenBuilders 結合了流式工廠來生成標準的查找、編輯和自定義界面。下面的例子展示了如何從一個界面打開另一個界面。注意，build() 方法能返回正確類型的界面實例，不需要不安全的類型轉換。
?
l?Screens 組件相對于 ScreenBuilders 來說提供了更底層的抽象，用來顯示和創建界面。并且提供了訪問 CUBA 應用程序中所有已打開界面信息的方法（Screens#getOpenedScreens），如果需要遍歷這些界面，這個方法很有用。
l?Notifications和Dialogs 組件均提供了自描述的方便接口。這里有個例子創建對話框和消息通知：
?
數據綁定
CUBA 之所以可以做到后臺UI的快速開發，不僅僅是因為提供了可以生成大部分代碼的可視化工具，還因為提供了大量開箱即用的具有數據感知能力的組件。 這些組件只需要知道要使用哪些數據，其余事情會自動管理。例如， 查找列表、選擇器字段、具有 CRUD 操作的各種網格等。
在版本 7 之前，數據綁定是通過稱為數據源的對象實現的，數據源包裝單個實體或實體集合、與數據感知組件綁定，然后響應數據感知組件的數據變化。 這種方法非常有效，但是是以一個整塊的方式實現的。 整塊石頭似的架構通常在可定制性方面會有問題。因此在 CUBA 7 中，這塊堅固的巨石被分成 3 個數據組件：
l?Data Loader (數據加載器）?是數據容器的數據提供者。 數據加載器不保存數據，它們只是將所有必需的查詢參數傳遞給數據存儲，并將結果數據集提供給數據容器。
l?Data container (數據容器) ?保留加載的數據（單個實體或多個實體）并以響應式的方式將數據提供給數據感知組件：被包裝實體的所有更改都會暴露給相應的UI組件，反之亦然，UI組件內的所有更改都會引起數據容器作出相應更改。
l?Data context??（數據上下文）是一個強大的數據更改管理器，可跟蹤更改并提交所有已修改的實體。 一個實體可以合并到一個數據上下文中，合并后會得到一個原始實體的副本，這個副本與原始實體有一個唯一但非常重要的區別：對副本實體及其引用的所有實體（包括集合）的所有修改都將被跟蹤、存儲和提交。
數據組件可以在界面描述符中聲明，也可以使用專門的工廠類 - DataComponents 以編程的方式創建。
其它
上面介紹了新的界面API中最重要的部分，所以剩下的部分我簡要列出 Web客戶端層中的其他重要功能：
URL 歷史記錄和導航。此功能解決了在 WEB 瀏覽器中具帶有“后退”按鈕的 SPA 應用程序存在的一個普遍問題，提供了一種簡單地為應用程序界面分配路徑的方法，同時使 API 能夠在URL中反映界面的當前狀態。
使用 Form 代替 FieldGroup。 FieldGroup 是一個數據感知組件，用于顯示和修改單個實體的字段。它在運行時推斷出用于顯示字段的實際UI組件。也就是說，如果你的實體中有一個日期類型的字段，它將使用 DateField 組件來顯示 。但是，如果你希望以編程方式使用此組件，則需要將此組件注入到界面控制器并手動將其轉換為正確的類型（在我們的示例中為DateField）。過了一段時間，可能會字段類型更改為其他類型，這時應用程序就是崩潰。表單通過顯式聲明組件類型解決此問題。關于 Form 的更多信息請參閱這里。
顯著地簡化了第三方 JavaScript 組件的集成，可參考這個文檔將自定義 JavaScript 組件嵌入到CUBA 應用程序中。
現在可以在 XML 界面描述中輕松定義 HTML/CSS屬性，也可以通過編程方式設置。詳細信息請參閱這里。
?
好了，以上只是關于 Studio 和偏前端的新功能介紹，下篇會介紹偏后端的新功能。
?
轉載于:https://www.cnblogs.com/cubacn/p/cuba-newversion.html
總結
以上是生活随笔為你收集整理的CUBA 7 新特性（上篇）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： RealsenseD435,D455参数
- 下一篇： 素材网 持续更新