Nhu cầu của JSF là gì, khi UI có thể đạt được với các thư viện JavaScript như jQuery và AngularJS

Tôi đã đọc về JSF rằng nó là một khung UI và cung cấp một số thành phần UI. Nhưng làm thế nào tốt hơn hoặc khác với số lượng các thành phần có sẵn từ jQueryUI, AngularJS, ExtJS hoặc thậm chí là HTML, CSS và JavaScript đơn giản.

Tại sao ai đó nên học JSF?

JSF sang đơn giản là JSP / Servlet / HTML / CSS / JS giống như jQuery với thuần JS: làm nhiều hơn với ít mã hơn. Để lấy PrimeFaces (dựa trên jQuery + jQuery UI) làm ví dụ, hãy duyệt qua phần giới thiệu của nó để xem các ví dụ mã hoàn chỉnh. BootsFaces (dựa trên giao diện người dùng jQuery + Bootstrap) cũng có một chương trình giới thiệu với các ví dụ mã hoàn chỉnh. Nếu bạn nghiên cứu kỹ các ví dụ đó, thì bạn sẽ thấy rằng về cơ bản bạn cần một lớp Javabean đơn giản làm mô hình và tệp XHTML dưới dạng xem.

Lưu ý rằng bạn không nên xem JSF là sự thay thế của HTML / CSS / JS một mình, bạn cũng nên đưa phần bên máy chủ vào tài khoản (cụ thể: JSP / Servlet). JSF loại bỏ sự cần thiết của tất cả các mẫu soạn thảo để thu thập các tham số yêu cầu HTTP, chuyển đổi / xác thực chúng, cập nhật các giá trị mô hình, thực thi phương thức Java phù hợp để thực hiện công việc kinh doanh và tạo mã soạn sẵn HTML / CSS / JS. Với JSF về cơ bản, bạn kết thúc với một trang XHTML dưới dạng định nghĩa xem và một lớp Javabean làm định nghĩa mô hình. Điều này làm tăng tốc độ phát triển.

Như với mọi khung công tác web dựa trên thành phần, bạn có trong JSF ít kiểm soát chi tiết hơn đối với HTML / CSS / JS được kết xuất. Việc thêm mã JS tùy chỉnh không dễ dàng như vậy vì bạn cũng phải đưa trạng thái khung nhìn JSF ở phía máy chủ (ví dụ: bật nút bị vô hiệu hóa ở phía JS sẽ không bật nút ở phía JSF, đến lượt nó lợi thế bảo mật rất lớn). Tuy nhiên, nếu đó là một showstopper chính, thì hãy tìm một khung công tác web dựa trên hành động như Spring MVC . Bạn sẽ chỉ đưa vào tài khoản mà bạn phải viết tất cả những gì HTML / CSS / JS đang tự . Ngoài ra, nếu bạn rơi trở lại từ Facelets sang JSP, bạn cũng sẽ bỏ lỡ các khả năng tạo khuôn mẫu nâng cao.

Mặt khác, nếu bạn có một trang web lớn dựa trên JSP / Servlet / HTML / CSS / JS / jQuery và bạn muốn cấu trúc lại mã mã nồi hơi lặp lại của JSP / Servlet / HTML / CSS / JS / jQuery thành các thành phần có thể sử dụng lại, sau đó một trong những giải pháp sẽ là JSF. Mẫu tùy chỉnh, tagfiles và các thành phần có thể hỗ trợ trong việc này. Trong viễn cảnh đó, JSF đứng trên JSP / Servlet / HTML / CSS / JS / jQuery (và đó cũng là lý do tại sao việc hiểu những điều cơ bản này trước khi đi sâu vào JSF) là rất quan trọng.

Bạn có thể tìm thấy một dự án dựa trên JSF khởi động thế giới thực tại đây: Ứng dụng Java EE Kickoff . Bạn sẽ thấy rằng nó chứa bên cạnh JSF là HTML5 , CSS3 và jQuery tốt .

Xem thêm:

• Sự khác biệt giữa Yêu cầu MVC và Thành phần MVC
• Sự khác biệt giữa JSP, Servlet và JSF
• Nên chọn khung web Java nào cho jQuery?
• Những nhược điểm chính của JSF 2.0 là gì?
• Có thể sử dụng JSF + Facelets với HTML 4/5 không?
• Khi nào nên sử dụng <ui: bao gồm>, tệp thẻ, thành phần hỗn hợp và / hoặc thành phần tùy chỉnh?

JSF được tạo ra để làm cho nó để các cửa hàng java không phải học những thứ như jQuery và xây dựng JS phức tạp mà thay vào đó tập trung vào một ngăn xếp thuần Java. Trong một thế giới nơi thời gian là tiền bạc và rất nhiều nơi đã tập trung vào phát triển Java, một ngôn ngữ / phần nhỏ hơn trong ngăn xếp giúp cho việc đào tạo và duy trì nhanh hơn và do đó rẻ hơn.

Tôi sẽ thêm rằng JavaScript rất dễ trở thành cơn ác mộng bảo trì đối với các nhóm lớn, đặc biệt nếu một số nhà phát triển trong dự án không hiểu biết nhiều về web.

Với Javascript và các khung công tác như jQuery, bạn có toàn quyền linh hoạt và toàn quyền kiểm soát. Với ext của vv, bạn mất nhiều quyền kiểm soát và phải thích ứng với khung. Với JSF, bạn hoàn toàn mất kiểm soát và phải hoàn toàn thích nghi với khung công tác. Bạn được gọi trong vòng đời, v.v. và cuối cùng bạn không kiểm soát được khi nào cuộc gọi đến máy chủ có thể được thực hiện và ở đâu không. Nếu bạn phải làm điều gì đó được coi là 'đặc biệt', bạn đang ở trong tình trạng rất khó khăn. Và trong thế giới JSF, ngay cả những thứ cơ bản như sắp xếp bảng nhiều lớp hoặc các trường mà bạn chỉ có thể nhập bộ ký tự giới hạn (chẳng hạn như trường số) được coi là 'đặc biệt'.

Tuy nhiên, bạn càng linh hoạt, bạn càng có nhiều lỗi hoặc thực hành xấu. Tính linh hoạt cao chỉ hoạt động với các lập trình viên rất thông minh, những người khác sẽ biến dự án thành cơn ác mộng không thể kiểm soát.

Nhưng, với JSF và tính linh hoạt hạn chế của nó, luôn luôn chỉ có một vài (hoặc thậm chí chỉ một) cách chính xác để làm một cái gì đó. Bạn rất hạn chế, bạn không thể tạo các phím tắt, bạn phải viết thêm XML, v.v. - nhưng khi thích nghi với tiêu chuẩn, sẽ có sự kiểm soát tốt hơn về mã mà các lập trình viên chưa có kinh nghiệm hoặc có tay nghề thấp sẽ tạo ra. Kết quả là, các tập đoàn lớn yêu thích JSF vì nó 'an toàn hơn' đối với họ.

Khi tôi chuyển từ GWT sang JSF, tôi đã bị sốc, có bao nhiêu điều, đó là điều tự nhiên đối với tôi, được coi là rất phi thường và bao nhiêu điều đơn giản rất khó đạt được. Hơn nữa, ngay cả khi thực hiện các thay đổi nhỏ nhất, chẳng hạn như thêm dấu ':' sau nhãn, trong ứng dụng được cung cấp bởi GWT / jQuery sẽ thay đổi một nhãn tạo chức năng, yêu cầu thay đổi hàng tá tệp với các thuộc tính được bản địa hóa, thậm chí không được xem xét bởi bất cứ ai ngoại trừ tôi lạ ...

Lợi ích của việc sử dụng JSF không chỉ trong việc tạo xhtml + css + js. Đôi khi, JSF áp đặt một hạn chế đối với đánh dấu mà bạn có thể tạo, giống như bất kỳ khung dựa trên thành phần nào. Nhưng JSF không chỉ vì điều đó, vòng đời của nó giúp rất nhiều. Sau khi xác thực đầu vào, nó có thể cập nhật mô hình và đồng bộ hóa các bean phía máy chủ của bạn mà không cần bất kỳ nỗ lực nào. bạn chỉ cần nói "bất cứ điều gì người dùng nhập vào đây, hãy kiểm tra xem đó có phải là số không, nếu có thì lưu trữ nó trong thuộc tính YY trong đối tượng XX" và JSF sẽ làm tất cả điều đó.

Vì vậy, có, bạn vẫn có thể sử dụng JQuery, JS, v.v. Nhưng JSF cung cấp nhiều lợi ích khi viết mã phía máy chủ và giúp bạn tiết kiệm được rất nhiều tấm nồi hơi.

Tôi hoàn toàn không đồng ý rằng jsf thêm bất cứ điều gì. Nó chỉ thêm chi phí. Làm công cụ ui trên máy chủ là điều vô lý nhất tôi từng nghe. Và javascript trên các nhóm lớn hoạt động rất tốt - nó được gọi là mã tái sử dụng.

Chỉ cần bọc jquery trong một số thẻ jsp, đó là tất cả những gì bạn cần và bạn đã hoàn thành, và không chịu đựng các vấn đề về khả năng mở rộng và khả năng mở rộng với.jsf và richfaces.

Đã làm việc với JSF, Spring MVC, Struts, Grails, JQuery và ExtJS, ý kiến ​​của tôi là Grails + ExtJS là một sự kết hợp mạnh mẽ.

Tôi sẽ chọn Grails hơn JSF bất cứ ngày nào. Tôi thích tính hoàn chỉnh của ExtJS với tư cách là khung và thư viện phía máy khách, nhưng nó đi kèm với một đường cong học tập dốc hơn JQuery.

Dưới đây là những khác biệt lớn nhất giữa jQuery & JSF:

• không có kiến ​​trúc MVC
• không kiểm soát trạng thái (ngày lưu trữ trong phiên hoặc cuộc trò chuyện, tự động dọn dẹp, v.v.)
• không có thư viện xác nhận (mặc định)
• không có thư viện templating
• không có điều hướng / định tuyến nâng cao
• phía khách hàng

jQuery không bao giờ có ý định được sử dụng như một webframework đầy đủ. Nó được dự định nhiều hơn để thay thế mã JS cấp thấp để việc viết JS trở nên dễ dàng và mạnh mẽ hơn trong ít dòng mã hơn.

Và do đó, phần lớn nên được sử dụng để thêm hành vi trên các phần tử HTML.

Đã sử dụng khung ExtJS cho một ứng dụng web lớn, tôi biết cách dễ dàng sử dụng. ExtJS (Schena) phù hợp nhất cho các tương tác cơ sở dữ liệu (Oracle 11g) trong kiến ​​trúc MVC. Chế độ xem dành cho các tương tác trực quan / người dùng. Bộ điều khiển đã chỉ định 'xử lý' và các trình kích hoạt cần được sử dụng tạo thành các gói PLQuery (API cho CRUD, các truy vấn chọn SQL, v.v.). Mô hình và các tệp lưu trữ đã được sử dụng để 'ánh xạ' các mục dữ liệu tới Trình xem / đầu vào.

ExtJS không phù hợp với các giao diện web không chuyên sâu về cơ sở dữ liệu - nơi Angular JS có thể phù hợp hơn.