Những nhược điểm chính của Java Server Faces 2.0 là gì?

Hôm qua tôi đã thấy một bài thuyết trình về Java Server Faces 2.0 trông thực sự ấn tượng, mặc dù tôi hiện đang là một nhà phát triển ASP.NET MVC / jQuery hạnh phúc. Điều tôi thích nhất ở JSF là số lượng lớn các thành phần UI được kích hoạt AJAX dường như giúp phát triển nhanh hơn nhiều so với ASP.NET MVC, đặc biệt là trên các trang web nặng AJAX. Kiểm thử tích hợp nhìn cũng rất đẹp.

Vì bài thuyết trình chỉ nhấn mạnh những lợi thế của JSF, tôi cũng muốn nghe về mặt khác.

Vì vậy, câu hỏi của tôi là:

• Những nhược điểm chính của Java Server Faces 2.0 là gì?
• Điều gì có thể khiến một nhà phát triển JSF cân nhắc sử dụng ASP.NET MVC thay vì JSF?

Nhược điểm của JSF 2.0? Thành thật mà nói, ngoài đường cong học tập tương đối dốc khi bạn không có kiến ​​thức nền tảng vững chắc về Phát triển Web cơ bản (HTML / CSS / JS, phía máy chủ so với phía máy khách, v.v.) và API Servlet Java cơ bản (yêu cầu / phản hồi / phiên , chuyển tiếp / chuyển hướng, v.v.), không có nhược điểm nghiêm trọng nào xuất hiện trong tâm trí. JSF trong bản phát hành hiện tại vẫn cần phải loại bỏ hình ảnh tiêu cực mà nó đạt được trong thời kỳ đầu, trong đó có một số nhược điểm nghiêm trọng.

JSF 1.0 (tháng 3 năm 2004)

Đây là bản phát hành ban đầu. Nó đã bị lộn xộn với các lỗi trong cả lĩnh vực cốt lõi và hiệu suất mà bạn không muốn biết. Ứng dụng web của bạn không phải lúc nào cũng hoạt động như bạn mong đợi bằng trực giác. Bạn là nhà phát triển sẽ khó khóc.

JSF 1.1 (tháng 5 năm 2004)

Đây là bản phát hành lỗi. Hiệu suất vẫn không được cải thiện nhiều. Ngoài ra còn có một nhược điểm lớn: bạn không thể nội tuyến HTML trong trang JSF một cách hoàn hảo. Tất cả HTML vanilla đơn giản được hiển thị trước cây thành phần JSF. Bạn cần bọc tất cả các vani đơn giản trong <f:verbatim>các thẻ để chúng được bao gồm trong cây thành phần JSF. Mặc dù điều này là theo đặc điểm kỹ thuật, điều này đã nhận được rất nhiều lời chỉ trích. Xem thêm ao JSF / Facelets: tại sao không nên kết hợp JSF / Facelets với các thẻ HTML?

JSF 1.2 (tháng 5 năm 2006)

Đây là bản phát hành đầu tiên của nhóm phát triển JSF mới do Ryan Lubke lãnh đạo. Nhóm mới đã làm rất nhiều công việc tuyệt vời. Cũng có những thay đổi trong thông số kỹ thuật. Sự thay đổi lớn là sự cải thiện của việc xử lý khung nhìn. Điều này không chỉ tách rời hoàn toàn JSF khỏi JSP, do đó, người ta có thể sử dụng công nghệ khung nhìn khác với JSP, nhưng nó cũng cho phép các nhà phát triển nội tuyến HTML vanilla đơn giản trong trang JSF mà không gặp rắc rối với <f:verbatim>các thẻ. Một trọng tâm lớn khác của nhóm mới là cải thiện hiệu suất. Trong suốt thời gian thực hiện Tham chiếu JSF Mặt trời 1.2 (có tên mã là Mojarra kể từ bản dựng 1.2_08, khoảng năm 2008), thực tế mọi bản dựng đều được cung cấp với các cải tiến hiệu suất (chính) bên cạnh các lỗi (thông thường) thông thường.

Nhược điểm nghiêm trọng duy nhất của JSF 1.x (bao gồm 1.2) là thiếu phạm vi ở giữa phạm vi yêu cầu và phiên , phạm vi được gọi là phạm vi hội thoại . Điều này buộc các nhà phát triển phải gặp rắc rối với các yếu tố đầu vào ẩn, truy vấn DB không cần thiết và / hoặc lạm dụng phạm vi phiên bất cứ khi nào muốn giữ lại dữ liệu mô hình ban đầu trong yêu cầu tiếp theo để xử lý thành công xác thực, chuyển đổi, thay đổi mô hình và yêu cầu hành động trong hơn ứng dụng web phức tạp. Nỗi đau có thể được làm dịu bằng cách áp dụng thư viện của bên thứ 3 lưu giữ dữ liệu cần thiết trong yêu cầu tiếp theo như thành phần MyFaces Tomahawk <t:saveState> , phạm vi hội thoại JBoss Seam và Dàn nhạc MyFaces khung hội thoại.

Một nhược điểm khác của những người theo chủ nghĩa thuần túy HTML / CSS là JSF sử dụng :ký tự dấu phân cách ID để đảm bảo tính duy nhất của phần tử HTML idtrong đầu ra HTML được tạo, đặc biệt là khi một thành phần được sử dụng lại nhiều lần trong chế độ xem (tạo khuôn mẫu, lặp lại các thành phần, v.v.) . Vì đây là một ký tự không hợp lệ trong số nhận dạng CSS, bạn sẽ cần sử dụng \để thoát dấu hai chấm trong bộ chọn CSS, dẫn đến các bộ chọn xấu và trông kỳ quặc như #formId\:fieldId {}hoặc thậm chí #formId\3A fieldId {}. Xem thêm Cách sử dụng ID phần tử HTML được tạo bởi JSF với dấu hai chấm ":" trong bộ chọn CSS? Tuy nhiên, nếu bạn không phải là người theo chủ nghĩa thuần túy, hãy đọc theo mặc định, JSF tạo ra các id không sử dụng được, không tương thích với một phần css của các tiêu chuẩn web .

Ngoài ra, JSF 1.x đã không giao hàng với các cơ sở Ajax ra khỏi hộp. Không thực sự là một bất lợi về kỹ thuật, nhưng do sự cường điệu của Web 2.0 trong khoảng thời gian đó, nó đã trở thành một bất lợi về chức năng. Exadel đã sớm giới thiệu Ajax4jsf, được phát triển kỹ lưỡng trong những năm qua và trở thành phần cốt lõi của thư viện thành phần JBoss RichFaces . Một thư viện thành phần khác cũng được vận chuyển với các quyền hạn Ajax dựng sẵn, một thư viện nổi tiếng là ICEfaces .

Khoảng nửa vòng đời của JSF 1.2, một công nghệ xem dựa trên XML mới đã được giới thiệu: Facelets . Điều này mang lại những lợi thế to lớn trên JSP, đặc biệt là trong lĩnh vực tạo khuôn mẫu.

JSF 2.0 (tháng 6 năm 2009)

Đây là bản phát hành lớn thứ hai, với Ajax là từ thông dụng. Có rất nhiều thay đổi về kỹ thuật và chức năng. JSP được thay thế bởi Facelets là công nghệ chế độ xem mặc định và Facelets được mở rộng với các khả năng để tạo các thành phần tùy chỉnh bằng cách sử dụng XML thuần (cái gọi là các thành phần hỗn hợp ). Xem thêm Tại sao Facelets được ưa thích hơn JSP làm ngôn ngữ định nghĩa khung nhìn từ JSF2.0 trở đi?

Sức mạnh Ajax đã được giới thiệu trong hương vị của <f:ajax>thành phần có nhiều điểm tương đồng với Ajax4jsf. Chú thích và cải tiến cấu hình quá mức đã được giới thiệu để tiêu diệtfaces-config.xml tệp verbose càng nhiều càng tốt. Ngoài ra, ký tự phân cách ID bộ chứa đặt tên mặc định có thể định :cấu hình được, vì vậy những người theo chủ nghĩa thuần túy HTML / CSS có thể thở phào nhẹ nhõm. Tất cả bạn cần làm là xác định nó như init-paramtrong web.xmlvới tên javax.faces.SEPARATOR_CHARvà đảm bảo rằng bạn không sử dụng các nhân vật cho mình bất cứ nơi nào trong ID khách hàng, chẳng hạn như -.

Cuối cùng nhưng không kém phần quan trọng, một phạm vi mới đã được giới thiệu, phạm vi xem . Nó đã loại bỏ nhược điểm lớn khác của JSF 1.x như được mô tả trước đây. Bạn chỉ cần khai báo bean @ViewScopedđể kích hoạt phạm vi hội thoại mà không làm phiền tất cả các cách để giữ lại dữ liệu trong các yêu cầu (hội thoại) tiếp theo. Một @ViewScopedbean sẽ tồn tại miễn là sau đó bạn gửi và điều hướng đến cùng một chế độ xem (độc lập với tab / cửa sổ trình duyệt đã mở!), Đồng bộ hoặc không đồng bộ (Ajax). Xem thêm Sự khác biệt giữa phạm vi Xem và Yêu cầu trong các hạt được quản lý và Cách chọn phạm vi đậu đúng?

Mặc dù thực tế tất cả các nhược điểm của JSF 1.x đã được loại bỏ, có những lỗi cụ thể của JSF 2.0 có thể trở thành một showstopper. Các @ViewScopedthất bại trong xử lý thẻ do một vấn đề gà-trứng trong tiết kiệm nhà nước một phần. Điều này được cố định trong JSF 2.2 và được nhập vào Mojarra 2.1.18. Ngoài ra, việc chuyển các thuộc tính tùy chỉnh như HTML5data-xxx không được hỗ trợ. Điều này được cố định trong JSF 2.2 bởi tính năng các yếu tố / thuộc tính thông qua mới. Hơn nữa, việc triển khai JSF Mojarra có các vấn đề riêng . Tương đối nhiều trong số họ có liên quan đến hành vi đôi khi unintuitive của<ui:repeat> , các phần thực hiện tiết kiệm nhà nước mới và phạm vi đèn flash thực hiện kém . Hầu hết chúng được cố định trong phiên bản Mojarra 2.2.x.

Trong khoảng thời gian JSF 2.0, PrimeFaces đã được giới thiệu, dựa trên jQuery và jQuery UI. Nó trở thành thư viện thành phần JSF phổ biến nhất.

JSF 2.2 (tháng 5 năm 2013)

Với sự ra đời của JSF 2.2, HTML5 đã được sử dụng làm từ thông dụng mặc dù về mặt kỹ thuật này chỉ được hỗ trợ trong tất cả các phiên bản JSF cũ hơn. Xem thêm Hỗ trợ JavaServer Faces 2.2 và HTML5, tại sao XHTML vẫn được sử dụng . Tính năng mới nhất của JSF 2.2 là hỗ trợ cho các thuộc tính thành phần tùy chỉnh, qua đó mở ra một thế giới khả năng, chẳng hạn như các nhóm nút radio không cần thẻ .

Ngoài các lỗi cụ thể khi triển khai và một số "điều nhỏ phiền toái" như không thể tiêm EJB vào trình xác nhận / trình chuyển đổi (đã được sửa trong JSF 2.3), không có nhược điểm thực sự nào trong đặc tả của JSF 2.2.

Thành phần dựa trên MVC và Yêu cầu dựa trên MVC

Một số người có thể lựa chọn rằng nhược điểm lớn của JSF là nó cho phép kiểm soát rất ít chi tiết đối với HTML / CSS / JS được tạo. Đó không phải là của riêng JSF, đó chỉ là vì nó là khung MVC dựa trên thành phần , không phải là khung MVC dựa trên yêu cầu (hành động) . Nếu mức độ cao của việc kiểm soát HTML / CSS / JS là yêu cầu chính của bạn khi xem xét khung MVC, thì bạn không nên xem xét một khung MVC dựa trên thành phần, mà ở một khung MVC dựa trên yêu cầu như Spring MVC . Bạn chỉ cần tính đến việc bạn sẽ phải tự viết tất cả các bản HTML / CSS / JS đó. Xem thêm Sự khác biệt giữa Yêu cầu MVC và Thành phần MVC .

Xem thêm:

• Sự khác biệt giữa JSF, Servlet và JSP là gì? (chỉ để hiểu những điều cơ bản)
• Sử dụng JSF để phát triển các bố cục CSS không cần thẻ (một huyền thoại khác về JSF)
• JSF so với HTML / CSS / JS / jQuery đơn giản (khi JSF là lựa chọn sai)
• Các mẫu thiết kế trong các ứng dụng web (minh họa ý thức hệ đằng sau MVC)

Sau 5 năm làm việc với JSF, tôi nghĩ rằng tôi có thể thêm 2 xu của mình.

Hai nhược điểm chính của JSF :

1. Đường cong học tập lớn. JSF rất phức tạp, điều đó chỉ đúng.
2. Bản chất thành phần của nó . Khung dựa trên thành phần cố gắng che giấu bản chất thực sự của Web, đi kèm với một số lượng lớn các sự phức tạp và thảm họa (như không hỗ trợ GET trong JSF trong vòng gần 5 năm).
   IMHO ẩn Yêu cầu / Phản hồi HTTP từ nhà phát triển là một sai lầm rất lớn. Từ kinh nghiệm của tôi, mọi khung công tác dựa trên thành phần đều thêm sự trừu tượng cho sự phát triển Web và sự trừu tượng hóa đó dẫn đến chi phí không cần thiết và độ phức tạp cao hơn.

Và những nhược điểm nhỏ xuất hiện trong đầu tôi:

1. Theo mặc định ID của đối tượng bao gồm id của cha mẹ của nó, ví dụ form1: button1.
2. Không có cách nào dễ dàng để bình luận ra đoạn không chính xác của trang. Thẻ <ui:remove>cần nội dung chính xác về mặt cú pháp được phân tích cú pháp.
3. Các thành phần bên thứ 3 chất lượng thấp, ví dụ như không kiểm tra isRendered()bên trong processXxx()phương pháp trước khi tiếp tục.
4. Kết hợp LESS & Sencha là khó.
5. Không chơi tốt với REST.
6. Không dễ dàng cho các nhà thiết kế UX, bởi vì các thành phần sẵn sàng sử dụng có các kiểu CSS riêng, cần được ghi đè.

Đừng hiểu lầm tôi. Là một khung thành phần, JSF trong phiên bản 2 thực sự tốt, nhưng nó vẫn dựa trên thành phần và sẽ luôn ...

Xin hãy xem mức độ phổ biến thấp của Tapestry, Wicket và sự nhiệt tình thấp của các nhà phát triển JSF có kinh nghiệm (điều còn có ý nghĩa hơn nữa). Và ngược lại, hãy xem thành công của Rails, Grails, Django, Play! Khung - tất cả đều dựa trên hành động và không cố gắng ẩn khỏi yêu cầu / phản hồi thực sự của lập trình viên và bản chất không trạng thái của web.

Đối với tôi đó là nhược điểm lớn của JSF. IMHO JSF có thể phù hợp với một số loại ứng dụng (mạng nội bộ, chuyên sâu về hình thức), nhưng đối với ứng dụng web thực tế thì đó không phải là một cách hay.

Hy vọng nó sẽ giúp ai đó với những lựa chọn của anh ấy / cô ấy liên quan đến front-end.

Một vài nhược điểm khiến bạn phải suy nghĩ:

1. JSF là một khung dựa trên thành phần. Điều này có những hạn chế cố hữu liên quan đến việc tuân theo mô hình thành phần.
2. AFAIK JSF chỉ hỗ trợ POST, vì vậy nếu bạn muốn NHẬN một nơi nào đó, bạn phải thực hiện một servlet / JSP đơn giản.
3. Hầu hết các thành phần cố gắng cung cấp trừu tượng trên các miền như cơ sở dữ liệu quan hệ và JavaScript mặt trước, và nhiều khi các tóm tắt này bị "rò rỉ" và rất khó gỡ lỗi.
4. Các tóm tắt này có thể là điểm khởi đầu tốt cho nhà phát triển cơ sở hoặc người không thoải mái với một tên miền cụ thể (ví dụ: JavaScript front-end), nhưng rất khó để tối ưu hóa hiệu suất, vì có một số lớp liên quan và hầu hết mọi người sử dụng chúng có ít hiểu biết về những gì đang xảy ra dưới mui xe.
5. Các cơ chế tạo khuôn mẫu thường được sử dụng với JSF không liên quan gì đến cách các trình giải mã web hoạt động. Các trình soạn thảo WYSIWYG cho JSF là nguyên thủy và trong mọi trường hợp, nhà thiết kế của bạn sẽ cung cấp cho bạn HTML / CSS mà bạn sẽ phải mất nhiều thời gian để chuyển đổi.
6. Những thứ như biểu thức EL không được kiểm tra tĩnh và cả trình biên dịch và IDE đều không làm tốt việc tìm lỗi, vì vậy bạn sẽ kết thúc với các lỗi mà bạn sẽ phải mắc vào thời gian chạy. Điều này có thể tốt cho ngôn ngữ được gõ động như Ruby hoặc PHP, nhưng nếu tôi phải chịu được sự phình to của hệ sinh thái Java, tôi yêu cầu nhập các mẫu cho tôi.

Tóm lại: Thời gian bạn sẽ tiết kiệm được với JSF, từ việc tránh viết mã mã nồi hơi JSP / servlet / bean, bạn sẽ sử dụng x10 để tạo tỷ lệ và thực hiện chính xác những gì bạn muốn.

Đối với tôi, nhược điểm lớn nhất của JSF 2.0 là đường cong học tập không chỉ của JSF, mà cả các thư viện thành phần mà bạn phải sử dụng để khiến nó thực hiện công việc hữu ích. Hãy xem xét số lượng đáng kinh ngạc của các thông số kỹ thuật và tiêu chuẩn mà bạn đã đối phó để thực sự thành thạo:

• HTML trong các hóa thân khác nhau. Đừng giả vờ rằng bạn không cần phải biết điều đó.
• HTTP - khi bạn không thể hiểu chuyện gì đang xảy ra, bạn phải mở Fireorms và xem. Cho rằng bạn cần phải biết điều này.
• CSS - Thích hay không. Nó thực sự không tệ và ít nhất có một số công cụ tốt.
• XML - JSF có thể sẽ là nơi đầu tiên bạn sử dụng không gian tên ở mức độ này.
• Đặc điểm kỹ thuật của Servlet. Sớm hay muộn bạn sẽ nhận được vào các phương thức gọi trong gói này. Ngoài ra, bạn phải biết Facelets của bạn được chuyển thành XHTML hay bất cứ điều gì.
• JSP (chủ yếu để bạn biết lý do tại sao bạn không cần nó trong JSF)
• JSTL (một lần nữa, chủ yếu là để đối phó với khung kế thừa)
• Ngôn ngữ biểu hiện (EL) trong các hình thức khác nhau của nó.
• ECMAScript, JavaScript hoặc bất cứ điều gì bạn muốn gọi nó.
• JSON - bạn nên biết điều này ngay cả khi bạn không sử dụng nó.
• AJAX. Tôi có thể nói rằng JSF 2.0 thực hiện tốt công việc che giấu điều này khỏi bạn nhưng bạn vẫn cần phải biết những gì đang xảy ra.
• DOM. Và một trình duyệt sử dụng nó như thế nào. Xem ECMAScript.
• Sự kiện DOM - một chủ đề của chính nó.
• Kiến trúc bền vững Java (JPA) đó là nếu bạn muốn ứng dụng của mình có bất kỳ cơ sở dữ liệu phía sau nào.
• Bản thân Java.
• JSEE trong khi bạn đang ở đó.
• Đặc tả kỹ thuật tiêm phụ thuộc bối cảnh (CDI) và cách nó đụng độ và được sử dụng với JSF 2.0
• JQuery - Tôi muốn thấy bạn hòa đồng mà không có nó.

Bây giờ, một khi bạn đã hoàn thành việc đó, bạn có thể tiếp tục với các thông số kỹ thuật độc quyền, cụ thể là các thư viện thành phần và thư viện nhà cung cấp mà bạn sẽ chọn trên đường đi:

• PrimeFaces (thư viện thành phần của sự lựa chọn của tôi)
• RichFaces
• MyFaces
• ICEFaces
• EclipseLink (Nhà cung cấp JPA của tôi)
• Ngủ đông
• Hàn

Và đừng quên container! Và tất cả các tệp cấu hình đó:

• GlassFish (2, 3, v.v.)
• JBoss
• Mèo con

Vì vậy - ĐÂY LÀ LÀM ĐƯỢC NÓ DỄ DÀNG? Chắc chắn, JSF 2.0 là "dễ dàng" miễn là tất cả những gì bạn muốn làm là các trang web cơ bản nhất với các tương tác đơn giản nhất.

Nói một cách đơn giản, JSF 2.0 là sự nhầm lẫn phức tạp và cồng kềnh nhất của các công nghệ được dán lại với nhau như tồn tại trong vũ trụ phần mềm ngày nay. Và tôi không thể nghĩ bất cứ điều gì tôi muốn sử dụng.

1. Các nhà phát triển thiếu kinh nghiệm thường sẽ tạo ra các ứng dụng rất chậm và mã sẽ thực sự xấu và khó bảo trì. Nó đơn giản để bắt đầu, nhưng thực sự đòi hỏi một số đầu tư vào việc học nếu bạn muốn viết các chương trình tốt.
2. Ít nhất là khi bắt đầu, bạn sẽ thường "mắc kẹt" trong một số vấn đề và sẽ dành nhiều thời gian hơn để đọc các bài đăng trên mạng hơn là thực sự làm việc :) Sau một thời gian, nó sẽ ngày càng ít đi, nhưng nó vẫn có thể gây phiền nhiễu.
3. Thậm chí còn khó chịu hơn khi bạn phát hiện ra rằng vấn đề không phải do bạn thiếu kiến ​​thức / sai lầm mà thực sự là một lỗi. Mojarra là (lỗi?) Khá lỗi, và một lớp thành phần khác lại thêm nhiều vấn đề hơn. Richfaces là phần mềm crap lớn nhất từng được viết :) Không biết bây giờ nó như thế nào trên phiên bản 4. Chúng tôi có Primefaces tốt hơn, nhưng bạn vẫn sẽ gặp lỗi hoặc thiếu tính năng đặc biệt là với các thành phần kỳ lạ hơn. Và bây giờ bạn sẽ cần phải trả tiền cho các bản cập nhật Primefaces. Vì vậy, tôi sẽ nói lỗi của nó nhưng nó đã trở nên tốt hơn đặc biệt là sau phiên bản 2.2 đã khắc phục một số vấn đề với thông số kỹ thuật. Framework ngày càng hoàn thiện nhưng vẫn còn lâu mới hoàn hảo (có lẽ myfaces tốt hơn?).
4. Tôi không thấy nó đặc biệt linh hoạt. Thông thường nếu bạn cần một cái gì đó rất rất tùy chỉnh và không có thành phần nào làm điều đó - nó sẽ hơi đau. Một lần nữa tôi đang nói từ góc độ nhà phát triển trung bình - người có thời hạn, hướng dẫn đọc nhanh và tìm kiếm stackoverflow khi gặp khó khăn vì không có thời gian để tìm hiểu cách nó thực sự hoạt động :) Thường thì một số thành phần dường như có "gần như" những gì bạn cần, nhưng không chính xác và đôi khi bạn có thể dành quá nhiều thời gian để làm cho nó làm điều gì đó bạn muốn :) Cần phải cẩn thận trong việc đánh giá xem có tốt hơn để tạo thành phần của riêng bạn hoặc tra tấn thành phần hiện có. Trên thực tế nếu bạn đang tạo ra thứ gì đó thực sự độc đáo, tôi sẽ không đề xuất JSF.

Vì vậy, trong ngắn hạn, nhược điểm của tôi sẽ là: Sự phức tạp, tiến độ phát triển không mấy suôn sẻ, lỗi, không linh hoạt.

Tất nhiên cũng có những lợi thế, nhưng đó không phải là những gì bạn yêu cầu. Dù sao đó là kinh nghiệm của tôi với khung mà những người khác có thể có ý kiến ​​khác nhau, vì vậy cách tốt nhất là hãy thử một lúc để xem nó có phù hợp với bạn không (chỉ là một thứ phức tạp hơn - không phải là ví dụ ngây thơ - JSF thực sự tỏa sáng ở đó :) JSF là các ứng dụng kinh doanh, như CRM, v.v ...

"JSF sẽ xuất ra HTML và JavaScript lớp View mà bạn không thể kiểm soát hoặc thay đổi mà không cần đi vào mã Trình điều khiển."

Trên thực tế, JSF mang đến cho bạn sự linh hoạt, bạn có thể sử dụng các thành phần tiêu chuẩn / bên thứ ba hoặc tạo thành phần của riêng bạn mà bạn có toàn quyền kiểm soát những gì được hiển thị. Nó chỉ là một xhtml mà bạn cần để tạo các thành phần tùy chỉnh của mình với JSF 2.0.

Tôi hoàn toàn không phải là chuyên gia về Máy chủ Java. Nhưng IMHO nhược điểm chính là phía máy chủ. Tôi mệt mỏi với việc học và sử dụng các khung công tác trình bày web phía máy chủ như ASP.NET Web Forms, ASP.NET MVC, Java Server Faces, Struts, php framework và ruby ​​trên rails framework. Tôi nói lời tạm biệt với tất cả bọn họ, và tôi nói xin chào với Angularjs và TypeScript. Lớp trình bày của tôi chạy trên trình duyệt. Tôi không quan trọng nếu nó được phục vụ bởi Windows IIS chạy php hoặc ASP.NET hoặc nếu nó được phục vụ bởi một máy chủ web Apache chạy trên Linux. Tôi chỉ cần học một khung làm việc ở mọi nơi.

Chỉ hai xu của tôi.

Chúng tôi đã phát triển một dự án mẫu với JSF (Đó là một nghiên cứu trong ba tuần để chúng tôi có thể mất một số thứ!)

Chúng tôi cố gắng sử dụng core jsf, nếu cần một thành phần, chúng tôi đã sử dụng PrimeFaces.

Dự án là một trang web với điều hướng. Mỗi trang nên được tải qua ajax khi nhấp vào menu.

Trang web có hai usecase:

1. Một trang có lưới. Lưới được tải thông qua ajax và nên hỗ trợ sắp xếp và phân trang
2. Một trang hướng dẫn ba bước. Mỗi trang có xác thực phía máy khách (đối với xác nhận đơn giản) và xác thực cơ sở ajax phía máy chủ (đối với xác thực phức tạp). Bất kỳ ngoại lệ máy chủ nào (từ lớp dịch vụ) phải được hiển thị trên cùng một trang của trình hướng dẫn mà không điều hướng đến trang tiếp theo.

Chúng tôi thấy rằng:

1. Bạn cần sử dụng một số hack từ omniFaces để làm cho trạng thái khung nhìn JSF được cố định. Trạng thái JSF sẽ bị hỏng khi bạn đưa các trang qua ajax vào nhau. Đây có vẻ là một lỗi trong JSF và có thể được sửa trong các bản phát hành tiếp theo (không phải trong 2.3).
2. Luồng JSF không hoạt động chính xác với ajax (hoặc chúng tôi không thể làm cho nó hoạt động được!)
3. Khi sử dụng một số thành phần jQuery như jqGird và bạn cần tải kết quả JSON, thì bạn nên sử dụng servlet thuần túy, JSF sẽ không làm gì cho bạn. Vì vậy, nếu bạn sử dụng các loại thành phần này, thiết kế của bạn sẽ không phù hợp với JSF.
4. Chúng tôi cố gắng thực hiện một số tập lệnh máy khách khi ajax hoàn thành ajaxCompletevà chúng tôi thấy rằng PF 4 đã thực hiện các sự kiện ajax của riêng mình. Chúng tôi đã có một số thành phần jQuery và chúng tôi cần thay đổi mã của chúng.

Nếu bạn thay đổi mẫu trên thành dự án không phải Ajax (hoặc ít nhất là ít dự án ajax), bạn sẽ không gặp phải nhiều vấn đề trên.

Chúng tôi tóm tắt nghiên cứu của chúng tôi là:

JSF không hoạt động tốt trong một trang web cơ sở ajax đầy đủ.

Tất nhiên, chúng tôi tìm thấy rất nhiều tính năng hay trong JSF có thể rất hữu ích trong một số dự án, vì vậy hãy xem xét nhu cầu dự án của bạn.

Vui lòng tham khảo các tài liệu kỹ thuật của JSF để xem xét các ưu điểm của JSF và theo tôi, ưu điểm lớn nhất của JSF, là hỗ trợ HOÀN THÀNH VÀ TUYỆT VỜI từ @BalusC ;-)

Đối với tôi, thiếu sót lớn nhất của JSF là sự hỗ trợ kém cho các trang được tạo theo chương trình (động).
Nếu bạn muốn xây dựng trang của mình (tạo mô hình thành phần trang) một cách linh hoạt từ mã java. Ví dụ: nếu bạn đang làm việc trên hàm tạo trang web WYSIWYG. Tài liệu đầy đủ của trường hợp sử dụng này thường không có sẵn. Có nhiều điểm mà bạn phải thử nghiệm và phát triển là yên tĩnh chậm. Nhiều thứ không hoạt động như bạn mong đợi. Nhưng nói chung có thể hack nó bằng cách nào đó.
Điều tốt là nó không phải là vấn đề trong triết lý hoặc kiến ​​trúc của JSF. Nó chỉ đơn giản là không được xây dựng đủ (theo như tôi biết).

JSF 2 mang đến các Thành phần hỗn hợp, giúp cho việc phát triển thành phần trở nên dễ dàng, nhưng sự hỗ trợ của chúng cho việc xây dựng năng động (lập trình) rất kém. Nếu bạn vượt qua quá trình xây dựng Thành phần hỗn hợp phức tạp và gần như không có giấy tờ, bạn sẽ phát hiện ra rằng nếu bạn lồng một vài thành phần hỗn hợp sâu hơn một chút, chúng sẽ ngừng hoạt động, đưa ra một số ngoại lệ.

Nhưng dường như cộng đồng JSF nhận thức được những thiếu sót này. Họ đang làm việc với điều này như bạn có thể thấy từ hai lỗi này
http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACESinksEC_PUBLIC-599

Tình hình nên tốt hơn với JSF 2.2 ít nhất nếu chúng ta đang nói về đặc tả.

Nhận xét về trải nghiệm Primefaces / JSF trong vài tháng qua của tôi:

• Nếu bạn có thể sử dụng các thành phần "ngoài giá", tôi đoán nó không khủng khiếp.
• Tuy nhiên, nó không chơi tốt ngay khi bạn bước ra ngoài và cần các UI tùy chỉnh. - Ví dụ: chúng tôi cần sử dụng bootstrap của Twitter cho dự án của chúng tôi. (Không phải bootstrap bootstrap).
  • Bây giờ các trang của chúng tôi hoạt động như sau:
    • Tải trang.
    • Người dùng tương tác với Primefaces có chức năng ajax
    • Các ràng buộc javascript của Bootstrap bị phá vỡ
    • Chúng tôi chạy thêm javascript để rebind mọi thứ

Lời hứa của JSF sẽ tránh việc viết javascript chuyển thành viết nhiều javascript hơn chúng ta sẽ có nếu không sử dụng Primefaces - và javascript đó sẽ khắc phục những gì Primefaces phá vỡ.

Đó là một khoảng thời gian - trừ khi bạn lại sử dụng công cụ "ngoài giá". Cũng thực sự xấu xí (Primefaces) khi phải làm việc với Selenium. Tất cả có thể được thực hiện - nhưng một lần nữa - chỉ có rất nhiều thời gian.

Chắc chắn tránh điều này nếu bạn đang làm việc với nhóm UX / nhóm thiết kế và cần nhanh chóng lặp lại trên UI - bạn có thể tiết kiệm thời gian bằng cách học jquery / viết HTML thẳng - hoặc nhìn vào phản ứng / góc cạnh.

JSF có nhiều ưu điểm, câu hỏi đang gặp bất lợi, hãy để tôi thêm vài điểm vào đó.

Trên một kịch bản thực tế của việc thực hiện một dự án web với khung thời gian, bạn cần theo dõi các yếu tố sau.

• Bạn có đủ thành viên cấp cao trong nhóm của mình, người có thể đề xuất các biện pháp kiểm soát tốt nhất phù hợp với từng kịch bản không?

• Bạn có băng thông để phù hợp với đường cong học tập ban đầu không?

• Bạn có đủ chuyên môn trong nhóm của mình, người có thể xem xét các
  công cụ JSF do các nhà phát triển tạo ra không?

Nếu câu trả lời của bạn là 'Không' cho các câu hỏi, bạn có thể kết thúc bằng một cơ sở mã không thể bảo trì.

JSF chỉ có một nhược điểm: trước khi bắt đầu phát triển "JSF", bạn nên hiểu rõ về phát triển web, java cốt lõi và kiến ​​trúc front-end.

Ngày nay, các khung JavaScript "mới" chỉ cần cố gắng sao chép / dán mô hình dựa trên thành phần "JSF".

Trong số tất cả các khung công tác "chính thống" như Spring MVC, Wicket, Tapestry, v.v., JSF của Java EE với các thành phần tổng hợp của nó là công nghệ định hướng thành phần và lớp trình bày phức tạp nhất được cung cấp. Nó hơi cồng kềnh và không đầy đủ so với các giải pháp được cung cấp bởi HybridJava.