Khi nào tôi nên sử dụng h: outputLink thay vì h: commandLink?


129

Khi nào tôi nên sử dụng <h:outputLink>thay vì một <h:commandLink>?

Tôi hiểu rằng commandLinktạo ra một bài viết HTTP; Tôi đoán rằng outputLinksẽ tạo ra HTTP được. Điều đó nói rằng, hầu hết các tài liệu hướng dẫn về JSF mà tôi đã đọc sử dụng commandLink(gần như?).

Bối cảnh: Tôi đang triển khai một dự án demo nhỏ, hiển thị liên kết tiêu đề đến trang người dùng, giống như ...

cần nhiều jquery

... Và tôi không chắc là commandLink(có lẽ sử dụng ?faces-redirect=trueđể đánh dấu trang) hay outputLinklà lựa chọn đúng đắn.

Câu trả lời:


195

Kết <h:outputLink>xuất lại một <a>phần tử HTML hoàn toàn xứng đáng với URL thích hợp trong hrefthuộc tính kích hoạt yêu cầu GET có thể đánh dấu. Nó không thể gọi trực tiếp một phương thức hành động được quản lý.

<h:outputLink value="destination.xhtml">link text</h:outputLink>

Phần tử <h:commandLink>kết xuất thành <a>phần HTML với onclicktập lệnh gửi biểu mẫu POST (ẩn) và có thể gọi phương thức hành động bean được quản lý. Nó cũng được yêu cầu phải được đặt bên trong a <h:form>.

<h:form>
    <h:commandLink value="link text" action="destination" />
</h:form>

Các ?faces-redirect=truethông số trên <h:commandLink>, mà gây nên một chuyển hướng sau khi POST (theo Post-Redirect-Nhận mẫu), chỉ cải thiện bookmarkability của trang mục tiêu khi liên kết được thực sự nhấp (URL sẽ không được "một đằng sau" nữa) , nhưng nó không thay đổi hrefthành <a>phần thành một URL hoàn toàn xứng đáng. Nó vẫn còn #.

<h:form>
    <h:commandLink value="link text" action="destination?faces-redirect=true" />
</h:form>

Kể từ JSF 2.0, cũng <h:link>có thể có ID xem (kết quả trường hợp điều hướng) thay vì URL. Nó sẽ tạo ra một <a>phần tử HTML cũng như với URL thích hợp trong href.

<h:link value="link text" outcome="destination" />

Vì vậy, nếu đó là để điều hướng từ trang đến trang thuần túy và có thể đánh dấu như liên kết tên người dùng SO, thì hãy sử dụng <h:outputLink>hoặc <h:link>. Điều đó cũng tốt hơn cho SEO vì các bot thường không mã hóa các biểu mẫu POST cũng như mã JS. Ngoài ra, UX sẽ được cải thiện vì các trang hiện có thể đánh dấu được và URL không còn "đứng sau" nữa.

Khi cần thiết, bạn có thể thực hiện công việc tiền xử lý trong hàm tạo hoặc @PostConstructcủa một @RequestScopedhoặc @ViewScoped @ManagedBeanđược đính kèm với trang đích được đề cập. Bạn có thể sử dụng @ManagedPropertyhoặc <f:viewParam>để đặt tham số GET làm thuộc tính bean.

Xem thêm:


2
Không, không phải như vậy. Chỉ UICommandcác thành phần cần phải đi trong một UIFormthành phần.
BalusC

3
Không, thực sự. Nói chung, khi bạn có thể, dính vào h:outputLinkhoặc h:linkcho các liên kết. SEO không nên được đánh giá thấp. Nhân tiện, đối với các URL giống như REST đẹp như ở đây trên SO, hãy xem PrettyFaces .
BalusC

1
Không, sự khác biệt là h:linklấy ID xem của JSF (ví dụ page) làm giá trị và h:outputLinklấy một URL thực (ví dụ /page.xhtmlhoặc /page.jsf, hoặc tùy thuộc vào FacesServletánh xạ của bạn ) làm giá trị. Mã hóa URL dù sao cũng xảy ra trong cả hai trường hợp. Nhân tiện, không có sự khác biệt giữa hành vi kết xuất của EL trong văn bản mẫu #{...}h:outputText. Cả hai đều thoát các thực thể XML được xác định trước (không, không giống như mã hóa URL). Các h:outputTextMời chỉ hơn attribtues thích id, styleClass, vv để kiểm soát thành phần và / hoặc đánh dấu.
BalusC

1
@BalusC Chính xác ý của bạn là "HTML xứng đáng" trong dòng đầu tiên của câu trả lời của bạn là gì?
Geek

1
@Geek: chỉ là một <a>yếu tố HTML duy nhất, không có gì khác, không huyền ảo , không có mã JS, v.v.
BalusC

4

Tôi cũng thấy rằng việc tải trang (hiệu suất) mất nhiều thời gian khi sử dụng h: commandLink hơn h: link. h: liên kết nhanh hơn so với h: lệnhLink


1
Tôi thấy khó tin. Ngoài tin đồn / bằng chứng giai thoại của riêng bạn, bạn có bất cứ điều gì để hỗ trợ điều đó?
Matt Ball

5
@Matt: Tôi có thể tưởng tượng rằng nó chậm hơn khi bạn có liên kết điều hướng POST này bên trong biểu mẫu "Thần" trong một trang với ví dụ có thể truy cập được với> 1000 hàng chứa 3 trường đầu vào mỗi hàng. Nhưng dù sao một trang như vậy cũng có những vấn đề nghiêm trọng khác :)
BalusC
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.