JSF2.3全新功能詳解，內附代碼對比

這篇文章中，Josh Juneau解釋了JSF 2.3的一些最新功能，包括新的API增強功能，CDI調整改進等。

Latte coffee image via Shutterstock.

JavaServer Faces（JSF）一直是Java EE平臺上開發Web應用程序中使用最廣泛的框架之一。該框架于2002年推出，允許程序員使用組件構建Web視圖，而不是從頭開始構建Web視圖，從而提供了構建Web應用程序的不同方法。組件允許程序員更多地關注應用程序的業務邏輯，并且花費更少的時間開發頁面操作和樣式，因為JavaScript和CSS被抽象出來。JSF還提供了一種不同的方法來處理應用程序狀態，狀態管理由框架處理。

多年以來，JSF得到了加強，使開發框架更加高效，并且與更新的Web技術保持一致。Facelets是框架的核心部分，允許程序員創建可輕松應用于應用程序中所有視圖的模板。引入了流程，提供了一種手段來跨越多個指定的視圖進行更詳細的會話管理，允許組件和視圖通過AJAX包含更好的客戶端和服務器端互操作性。這些只是幫助將JSF框架改進成為當今頂級Web框架的一些改進。

JSF的最新版本是2.3版，其中包含了許多新功能，從而使Java 8和其他現代Web框架得到了加速。由于有許多資源可以解釋如何使用JSF，本文將介紹JSF2.3發行版中包含的最新功能。此版本的重點是更好地與Java SE 8和CDI進行對齊，還有一個基于社區請求的小型新功能集。

改進的CDI對齊和易用性

也許JSF 2.3最受追捧和有用的補充之一是CDI對齊改進。JSF 2.3提供了許多生產力增強功能，因為許多JSF工件現在可以輕松地注入到Java類和EL表達式中。多年來，JSF的一個難點就是要利用靜態輸入法和鏈接來獲取諸如FacesContext，RequestMap或FlowMap之類的一些組件。這些組件現在可以輕松地注入到類中，而不是實例化?；蛟S程序員曾經做過以下事情：

在JSF 2.3中，可以簡單地執行以下操作：

如果在JSF視圖中的EL表達式的上下文中使用，可以執行以下操作：

有許多需要CDI限定詞的組件。例如FlowMap注入，如下：

JSF Managed Bean的范圍在過去幾年似乎有點混亂，不過可以利用Managed Bean注釋以及CDI進行范圍界定。隨著JSF 2.3的發布，托管Bean注釋已被棄用，因為CDI現在是首選方法。這樣做有助于防止開發人員在混合Managed Bean和CDI范圍注釋時引入錯誤，因為它們不能很好的共同發揮。因此，@ ManagedProperty注釋已被棄用。此版本引入了更新的@ManagedProperty注釋，允許相同的功能繼續可用。

網絡和WebSockets更新

WebSocket是通過TCP提供全雙工雙向通信的協議。它已經成為不斷增長的異步環境中的標準通信協議。雖然JSF已經很好地與WebSocket通信工作了很長時間，但2.3版本完全支持它，通過新的<f：websocket>標簽使WebSockets成為一流的功能。新標簽可以放置在一個視圖中，以便將服務器端通信推送到包含相同通道名稱的套接字的所有實例。當接收到通信時，可以調用一個消息處理JavaScript事件處理程序，從而提供客戶端功能。使用新標簽的示例可能如下所示，當接收到該消息時，該標簽只會顯示警報：

WebSocket通信的服務器端能夠推送消息。JSF 2.3添加了javax.faces.push.PushContext，它是一個可注入的上下文，允許服務器推送到命名通道。

JSF 2.3中還有其他網絡和AJAX增強功能，其中包括：

使用新的<h：commandScript />組件從視圖執行任意的服務器端方法。
通過PartialViewContext從服務器端方法執行視圖中的JavaScript。
通過新引入的“命名空間”模式，使用AJAX更新多個表單。

驗證和轉換增強

已經為此版本提供了許多有用的驗證和轉換增強功能，包括更好的Java SE 8對齊以及驗證整個bean的能力。通過使用新的<f：validateWholeBean>標簽，可以實現類級別的bean驗證。通過在視圖中包含此標記并使用bean驗證組標記至少一個輸入組件，可以驗證整個bean，從而實現新的驗證支持。

自從Java SE 8發布以來，大部分Java程序員都在使用新的Date-Time API。Java EE不得不使這個新的API可以繼續工作，并且隨著JSF2.3版本的向前推進，增強了<f：convertDateTime>轉換標簽，以支持新的日期時間類型。例如，要使用java.time.LocalDate類，可以在視圖中使用以下內容：

增強的<f：convertDateTime>支持以下日期時間類型：LocalDate，LocalTime，LocalDateTime，OffsetTime，OffsetDateTime和ZonedDateTime。

組件和API增強功能

自JSF成立以來，各種組件和API都出現了一些細微差別，有時使得開發很麻煩。為了解決這些問題，新版對底層API和組件的數量進行了增強。例如，UIData和UIRepeat已被增強，以支持Map和Iterable接口以及自定義類型。這些增強功能可以在DataTable和ui：repeat標簽中支持java.util.Iterable類型，Maps和自定義數據類型。例如，DataTable中的地圖支持如下所示：

還有許多其他有用的增強功能，包括通過新標簽在EL中使用常量的能力。多年以來，JSF已經缺少了一些基本功能，例如在視圖中放置單選按鈕的功能。2.3版本通過提供以下功能減少了追查功能的數量：

通過<h：selectOneRadio>上的新組屬性提供獨立單選按鈕
在<h：column>中添加了styleClass屬性，以增強樣式支持
在<h：dataTable>上添加了rowClass屬性，以增強樣式支持
自動收集轉換<h：selectManyMenu>標簽

結語

JSF 2.3提供了許多增強功能和新功能，使框架更輕松，更靈活。Oracle和Java社區的程序員聚集在一起，使此版本比原來計劃的更強大。本文列出的許多功能都來自于社區的要求，JSR 372專家組的社區成員完成了大量工作。

很長的一段時間中，Vue 官方都以簡單上手作為其推廣的重點。這確實給 Vue 帶來了非常大的用戶量，尤其是最追求需求開發效率，往往不那么在意工程代碼質量的國內中小企業中，Vue 占據的份額極速增長。但是作為開發者自身，我們必須要認清一個重點，簡單易用從來不應該在技術選型中占據很大的份額，可維護性才是。

以防萬一有的同學實在不看官方文檔，我先提一嘴，SFC 就是寫 Vue 組件的時候寫的.vue文件，這一個文件就是一個 SFC，全稱 Single File Component，也即單文件組件。

在開始說我個人的觀點之前，我們先來看幾個事實：

一是：Vue3 的定義原生支持 JSX，并且 Vue3 源碼中有jsx.d.ts來便于使用 JSX。 不知道同學們看到這里會想到什么，我的第一反應是：社區對于 JSX 的需求聲音是不小的，所以會反向推動 Vue3 官方對于 JSX 的支持。

二是：AntDesign 的 vue3 版本，基本全部都是用 JSX 開發的，而且 Vue3 現在官方的 babel-jsx 插件就是阿里的人一開始維護的，雖然我向來不喜歡阿里系的 KPI 推動技術方式，而且現在的 JSX 語法支持也不是很符合我的期望，但至少在使用 JSX 開發是更優秀的選擇這點上，我還是很認可 AntDesign 團隊的。

OK，說這些呢，主要是先擺出一些事實作為依據，讓有些同學可以不需要拿什么：

啊，這都是你空想的，你太自以為是了
你再怎么想都沒用，咱們 Vue 就是應該用 SFC 開發

這些觀點來批斗我，首先我都會從客觀的角度來分析為什么，至少是我是能講出優劣勢的理由的。

OK，前言差不多到這里，接下來咱給您分析分析，為什么你應該選擇 JSX 來開發 Vue。

TypeScript 支持

其實第一點就已經是殺手了，對于想要使用 TypeScript 來開發 Vue3 應用的同學來說，這簡直就是 SFC 無法克服的世界難題。

一句話概括：TypeScript 原生支持 JSX 語法，而基本無望 TS 官方能支持 SFC 的 template 語法。

TS 毫無疑問在前端社區的重要性越來越大，但凡未來對于代碼質量有一定要求的前端團隊，都應該會選擇使用 TS 來進行開發。而且現在基本上在 NPM 上都能看到包你都能找到對應的 TS 定義，現在使用 TS 開發成本已經只剩下你是不是會 TS 語法了，在這種情況下是否支持 TS 則是開發模式在未來走不走的遠的重要原因。

目前 SFC 只能通過shim讓 TS 可以引入.vue文件，但是對于所有 SFC 的組件的定義都是一樣的：

declare module '*.vue' {
    import { DefineComponent } from 'vue'
    const component: DefineComponent<{}, {}, {}, any>
    export default component
}

也就是說你引入的 SFC 組件，TS 是不知道這個組件的 Props 應該接收什么的。所以你無法享受到這些 TS 的優勢：

開發時的自動提示
編譯時的 TS 校驗，讓你盡早發現問題
編譯組件生成你的組件定義（對于類庫開發尤其重要）

當然你會說既然 Vue 官方能開發處 SFC 的語法，自然會支持這些特性。我表示這當然有可能，但是這個難度是非常大的，需要很多方面的支持，甚至可能需要 TS 官方團隊愿意協助，但是我想不到 TS 官方有什么理由來支持 SFC，因為這只是 Vue 自己創建的方言，在其他場景下是沒有使用的，TS 是面向全社區的，我覺得他們不會考慮主動來支持 SFC。

那么有同學要問了，JSX 不也是非原生的 JS 語法么，他怎么就能讓 TS 官方支持了呢，是不是 FB 和微硬之間有什么 PY 交易？

這就涉及第二點了，JSX 和靜態模板的靈活性區別。

JSX 其實并不是方言

很多人弄錯了一個問題，就是覺得 SFC 的模板語法和 JSX 是一樣的，都是一種別人發明的語法，并不是 JS 原生的。這是事實，但又有一些區別，這個區別主要是體現在對于 JSX 的認知上。

一句話概括：JSX 并沒有擴展 JS 的語法，他只是縮略了 JS 的寫法！其本質就是 JS 的語法糖

就像 es6 給增加的語法糖，比如

const a=1
const b=2

const obj={ a, b }

// 其實就等價于
const obj={ a: a, b: b }

這種寫法并沒有擴展 JS 的能力，只是簡便了寫法，JSX 也是一樣的。

JSX 其實就是方法調用，他和 JS 是有一對一對應關系的，我們來看一個例子：

const element=<div id="root">Hello World</div>

這里的 JSX 語法編譯之后其實就是：

const element=createElement('div', { id: 'root' }, 'Hello World')

而 JSX 就是這些了，沒有什么更多的內容，所以說 JSX 只是方便我們寫嵌套的函數調用的語法糖，而其本身沒有擴展任何其他的內容。

但是 SFC 就不一樣了。

SFC 定義的不僅是語法，更是文件。

SFC 的具體定義是單文件組件，它本身就是把一個文件看作一個單位，所以他的約束性是要大很多的，你必須具有固定的文件結構才能使用 SFC，這做了很多的限制：

一個文件只能寫一個組件
節點片段只能寫在 template 里面，非常不靈活
變量綁定只能獲取this上面的內容，不能使用全局變量（很多時候我們都要把全局變量先掛載到this上）

我們一點點來講

一個文件只能寫一個組件

這個說實話非常非常不方便，很多時候我們寫一個頁面的時候其實經常會需要把一些小的節點片段拆分到小組件里面進行復用（如果你現在沒有這個習慣可能就是因為 SFC 的限制讓你習慣了全部寫在一個文件內）。

React 生態中豐富的 css-in-js 方案就是很好的例子，我們可以通過：

const StyledButton=styled('button', {
    color: 'red',
})

如果我們這個頁面需要使用特定樣式的按鈕，通過這種方式在頁面文件里面封裝一下是非常常見的。因為沒必要把這個組件拆分出去，他也不是一個可復用的組件，拆分出去了還要多一次import。

Vue 生態基本沒有 css-in-js 的成熟方案其實跟這個限制也很有關系。

再來一個例子，比如我們封裝了一個 Input 組件，我們希望同時導出 Password 組件和 Textarea 組件來方便用戶根據實際需求使用，而這兩個組件本身內部就是用的 Input 組件，只是定制了一些 props：

const Input={ ... }

export default Input

export const Textarea=(props)=> <Input multiline={true} {...props} />

export const Password=(props)=> <Input type="password" {...props} />

在 JSX 中可以非常簡單地實現，但是如果通過 SFC，你可能就要強行拆成三個文件，另外為了方便，你可能還要增加一個index.js來導出這三個組件，你能想象這多了多少工作量么。

節點片段只能寫在 template 里面，非常不靈活

我不知道有多少同學看過 Vue 的 template 編譯出來之后的代碼，以我的經驗來說看過的可能不會超過 50%（樂觀估計），建議同學們如果還不了解的，可以去嘗試看一下。

為什么要看這個呢？因為你看了之后你會發現，你在 template 里面寫的類似 HTMl 的內容，其實跟 HTML 根本沒啥關系，他們也會被編譯成類似 JSX 編譯出來的結果。

{
    render(h) {
        return h('div', {on: {}, props: {}}, h('span'))
    }
}

類似這樣的結果，而這里面h函數調用的結果就是一個 VNode，是 Vue 中的節點的基礎單元。那么既然這些單元就是一個對象，其實理所當然的，他們是可以作為參數傳遞的。也就是說，理論上他們是可以通過props把節點當作參數傳遞給其他組件的。

這個做法在 React 中非常常見，叫做renderProps，并且其非常靈活：

const Comp=()=> <Layout header={<MyHeader />} footer={<MyFooter />} />

但是因為 SFC 模板的限制，我們很難在 SFC 里面的 props 上寫節點：

<template>
    <Layout :header="<MyHeader/>"></Layout>
</template>

這樣寫是不行的，因為 SFC 定義了:header綁定接受的只能是 js 表達式，而<MyHeader/>顯然不是。

因為通過 props 傳遞不行，所以 Vue 才發明了 slot 插槽的概念

雖然我們一直再說 Vue 簡單，但是事實上ScopedSlots一度成為新手理解 Vue 的噩夢，很多同學都被這個繞來繞去的作用域整的死去活來。

我們看一個ScopedSlots的例子：

<template>
    <Comp>
        <template v-slot:scope="ctx">
            <div>{{ctx.name}}</div>
        </template>
    </Comp>
</template>

這里ctx是Comp里面的屬性，通過這種方式傳遞出來，讓我們在當前組件可以調用父組件里面的屬性。這簡直就是理解的噩夢，但是如果用 JSX 實現類似功能就非常簡單：

<Comp scope={name=> <div>{name}</div>} />

我們只是給一個叫做scope的 props 傳遞來一個函數，這個函數接受一個name屬性，在Comp里面會調用這個函數并傳入name。簡單來說我們傳入的就是一個構建節點片段的函數，就是這么簡單。

這就是因為 SFC 的模板的限制，導致靈活性不足，Vue 需要去創造概念，創造關鍵字來抹平這些能力的不足，而創造的概念自然就引入了學習成本。

所以其實我一直不認可 Vue 比 React 好學的說法的，如果你真的認真研究所有用法，并且總是嘗試用最合理的方式實現功能，那么 Vue 絕對不會比 React 簡單。

變量綁定只能獲取this上面的內容，不能使用全局變量

這個體現在兩個方面，一個是我們定義在全局的一些固定數據如果要在組件內使用的話，就要通過this掛載到組件上。

比如我們緩存了一份城市數據，這種數據基本上是不會改的，所以也沒必要掛載到組件上讓其能夠響應式。但是在 SFC 里面這是做不到的，因為模板的執行上下文是在編譯時綁定。你在模板里面訪問的變量，都會在編譯時自動綁定到this上，因為模板需要編譯，其本身也是字符串不具有作用域的概念。

而這在 JSX 中則不復存在：

const citys=[]

const Comp=()=> {
    return citys.map(c=> <div>{c}</div>)
}

另外一個方面則是在組件使用上，在 SFC 中，組件必須事先注冊，因為我們在模板里面寫的只能是字符串而不能是具體某個組件變量。那么模板中的組件和真實的組件對象只能通過字符串匹配來實現綁定。這帶來了以下問題：

多了注冊組件這個步驟，增加代碼量
通過字符串名注冊自然就會出現可能的沖突問題
模板解析組件支持不同的樣式，比如<MyComp>和<my-comp>，容易導致風格不一的問題

在 JSX 中則沒有這些問題，因為 JSX 里面直接使用組件引用作為參數：

const Comp={...}

const App=()=> <Comp />

需要通過directive來擴展能力

其實上面能看出來，除了 SFC 本身的問題之外，Vue 使用字符串模板也會帶來很多的靈活性問題。最直接的證據，就是 Vue 使用了directive來擴展功能（當然這不是 Vue 發明的，老早的模板引擎就有類似問題）。

為什么說directive是不得已的選擇呢？因為靜態模板缺失邏輯處理的能力。我們拿列表循環舉例，在 JS 中我們可以非常方便地通過map函數來創建列表：

const list=arr.map(name=> <span key={name}>{name}</span>)

而因為 JSX 本身就是函數調用，所以上面的代碼和 JSX 結合起來也非常自然：

const App=()=> (
    <div>
        <Header />
        {arr.map(name=> (
            <span key={name}>{name}</span>
        ))}
    </div>
)

上面的例子對應到 JS 如下：

const App=()=>
    createElement('div', {}, [
        <Header />,
        arr.map(name=> createElement('span', { key: name }, name)),
    ])

這仍然是因為 JSX 只是 JS 的語法糖的原因，所有能在 JS 中實現的在 JSX 里面都能實現。

而 SFC 的模板是基于字符串編譯的，其本身就是一段字符串，我們不能直接在模板里面寫map來循環節點，（當然我們可以在可以接收表達式的地方寫，比如v-on里面）。

那么我們不能循環節點，有需要這樣的功能來渲染列表，怎么辦呢？就是發明一個標志來告訴編譯器這里需要循環，在 Vue 中的體現就是v-for指令。

同學們可能要問了，既然 Vue 能實現v-for，為什么不直接實現表達式循環列表呢？他當然也可以實現，但是他肯定不會這么選，因為成本太高了。他要這么做就相當于他要實現一個 JS 引擎，而其實里面很多內容又是不必須的，一個v-for其實就能夠適用大部分情況了。

但有了v-for就需要v-if，那么后面還會需要其他各種能力，這就是一種方言的產生和發展的過程。

當然指令也不僅僅是 JS 表達式的代替品，其本身也是增加了一些其他能力的，比如它能夠讓我們更方便地訪問 DOM 節點，但是嘛，我們用框架的理由不就是為了能夠盡可能的屏蔽 DOM 操作嘛～

總結

以上就是我對應該選擇使用 JSX 還是 SFC 進行開發的分析，其實歸根到底 SFC 的問題在于其沒有擁抱 JS，他的語法是自己發明的，他需要有一個 JS 實現的 compiler 來讓其最終能在 JS 環境中運行，這本質上就是一種發明，我們不能否認發明確實有優點，但我們也不能只看有點不看問題，沒能擁抱 JS 自然就很難完全復用 JS 社區的優勢而 JS 社區一直在蓬勃發展，好用的工具一直在涌現，而 SFC 想要使用 JS 社區的這些工具還要自己再實現一份，我們可以細數以下 SFC 做了哪些兼容

vue-loader 之于 webpack
eslint-plugin-vue 之于 eslint
rollup-plugin-vue 之于 rollup
vue-jest 之于 jest
Vetur 用來做代碼提醒

基本上常用的工具我們都需要等待 Vue 社區或者官方開發了插件之后才能運行。而 JSX 因為有 babel 和 typescript 的官方支持，基本上所有新的 JS 生態工具原生都是支持的。

在這 Vue3 開始預備發力的階段，我們還是希望 Vue 社區能夠使用更優秀更規范的方式來進行開發，其實如果我們直接使用 JSX 開發 Vue3，我們會發現很多時候我們都不需要用到emit、attrs這些概念，甚至如果 Vue3 的 JSX 插件支持，我們甚至能夠拋棄slots。

但是因為 Vue3 一定要考慮兼容 Vue2，導致本身潛力很好的 Vue3 總是顯得縮手縮腳，這不得不說是一種遺憾。

ava-Server-Faces 是一種被很多人低估的 Web 技術。這是為什么？如果你還在使用 JSF，你真的瘋了嗎？

規范

首先，JSF 是一種規范，與 JSF 通常與之相比的所有其他技術相比，它具有重要優勢。該規范是一個開放的過程，多年來一直伴隨著許多開發人員為 Web 應用程序定義一個通用的可靠標準。這個規范過程最近發生在 Eclipse Foundation 中，它建立了遵循非常高質量標準的規則。這是最大的優勢之一，因為它保證您的 Web 應用程序構建在一個堅實的核心之上。當然，其他 Web 框架也有大型社區，但這些社區通常由一家公司代表，并不總是將開發人員考慮在內。來自 Google 的 Angular 只是一個例子。

基于服務器的框架

但回到 JSF。為什么 JSF 有時會被嘲笑為過時的技術？我個人是在 2001 年初開始使用 JSF 的。所以它顯然是一項古老的技術。我也是一個老開發者;-)。與此同時，許多其他 Web 框架也在發展。其中許多基于 JavaScript，并遵循在瀏覽器中運行的單頁范例 (SPA)。這個想法是將應用程序邏輯移動到瀏覽器中以更快地獲取應用程序。這個想法是在不是每個人都對 JSF 感到滿意的時候提出的，并且 JavaScript 開始流行起來。Java Server Faces——顧名思義——相反，是一個基于服務器的框架。這意味著應用程序邏輯在服務器上執行。這就是我們有很大不同的地方。當時，減少服務器負載是一個有效的論據。而且當然，這在今天仍應是一個可取的目標。但是，以此作為反對 JSF 的論據的人通常是對無服務器功能贊不絕口的人。因此，我認為我們今天不應該將基于服務器的框架視為愚蠢的想法。

自包含的微服務

基于服務器的 Web 框架提供了一些優勢。這樣，應用邏輯和業務邏輯可以很容易地耦合。這是在 Jakarta EE 中實現的，主要是通過 CDI、EJB 和 JPA。這些技術是 JSF 組件的后端。Jakarta EE 對層的分離提供了非常清晰的理解，而 JSF 無縫地融入了這一概念。服務器端實現還對客戶端隱藏了應用程序細節。相比之下，在 JavaScript SPA 中，大部分應用程序邏輯通常在瀏覽器中不受保護，這在某些情況下可能存在安全風險。

因此，在服務器端呈現應用程序邏輯使負責后端和前端部分的開發人員更容易。這導致在許多情況下可以更快地開發應用程序。從微服務架構的角度來看，一個 JSF 應用程序對應于Self-Contained Services的原則。這是微服務架構中常用的一種模式。

簡單

由于 JSF 通常被稱為復雜和笨拙，我最近想知道這是否真的如此。我將我的一個 Vue.js SPA 遷移到 JSF 4.0 并比較了生成代碼的復雜性。所以最后，我想通過一個例子來展示 JSF 的簡單性。（注意：我這里不比較 JavaScript 代碼和 Java）

在 JavaScript 框架中，您通常通過附加標記將 HTML 標記綁定到某些代碼。

<input type="text" name="userwebsite" v-model="userwebsite" placeholder="enter your website">Your Website is: <span>{{api}}</span>

SPA 框架解析標簽 (v-model) 并從用 JavaScript 編寫的模型中放置正確的值。它還綁定輸入字段以跟蹤模型中的更改。

JSF 對應項看起來并沒有太大不同：

<h:inputText value="#{userController.website}" pt:placeholder="enter your website" />Your Website is: <h:outputText value="#{userController.website}" />

在這里，您還將模型值綁定到輸入字段或輸出文本。但是代碼在服務器端用 Java 執行，這通常等同于用 Java 編寫的后端代碼，也適用于 SPA。

開箱即用的 JavaScript Web 框架使用 Ajax。所以你通常不需要關心它。在上面的例子中，span，一個標簽會在輸入值改變時自動更新。

在 JSF 中，您也使用 Ajax，但您可以更好地控制它的行為方式。您可以簡單地使用 f:ajax 標記將頁面的一部分括起來以獲得相同的行為：

<f:ajax> <h:inputText value="#{userController.website}" pt:placeholder="enter your website" /> Your Website is: <h:outputText value="#{userController.website}" /><f:ajax>

另一個例子是鏈接。在 JavaScript 框架中，當用戶單擊元素時，您再次使用一種標記來啟動渲染生命周期：

<li class="nav-item" v-on:click="showSection('search')"> <label>Search</label></li>

在您的showSectionJavaScript 代碼中實現一些業務邏輯，并負責處理數據和更改布局。

JSF 并沒有太大的不同：

<li class="nav-item"> <h:link outcome="search" > <label>Search</label></li>

該h:link標記從名為“search.xhtml”的后端加載一個包含新布局的新頁面。所有模型綁定都在后臺后臺處理。對于用戶而言，行為沒有區別。

因此，正如您從標記中看到的那樣，沒有太大區別，編寫 JSF 前端并不像在基于 JavaScript 的 Web 框架中那樣復雜。

我個人的結論是，JSF 為我在框架內編寫代碼提供了更清晰、更一致的概念。后端邏輯和應用程序設計結合在一種技術中，從而形成一種模式，也稱為自包含微服務。

對我來說，即使對于現代 Web 應用程序來說，這也是一個有效的概念。而在服務器端計算應用邏輯一點也不瘋狂。

使用 JSF 版本 4.0，您會發現一種現代且設計良好的 Web 技術嵌入到最新的Jakarta EE 10 框架中。

在線咨詢

上一篇：Programming abstractions i
下一篇：用純CSS實現優惠券剪卡風格

您的項目需求

*請認真填寫需求信息，我們會在24小時內與您取得聯系。

整合營銷服務商

JSF2.3全新功能詳解，內附代碼對比