Tại sao tôi sử dụng công cụ tạo khuôn mẫu? jsp bao gồm và jstl vs ô, freemarker, tốc độ, sitemesh

Tôi sắp chọn cách sắp xếp chế độ xem của mình (với spring-mvc, nhưng điều đó không quan trọng lắm)

Có 6 tùy chọn theo như tôi thấy (mặc dù chúng không loại trừ lẫn nhau):

• Gạch
• Sitemesh
• Nhà thương mại
• Vận tốc
• <jsp:include>
• <%@ include file="..">

Các ô và Sitemesh có thể được nhóm lại; vì vậy có thể Freemarker và Velocity . Cái nào trong mỗi nhóm sử dụng không phải là vấn đề của cuộc thảo luận này, có đủ câu hỏi và thảo luận về nó.

Đây là một bài đọc thú vị , nhưng không thể thuyết phục tôi sử dụng gạch.

Câu hỏi của tôi là - những gì các khuôn khổ này cung cấp mà không thể được thực hiện đúng với <@ include file=".."> và JSTL. Những điểm chính (một số trích từ bài báo):

1. Bao gồm các phần của trang, như đầu trang và chân trang - không có sự khác biệt giữa:

   <%@ include file="header.jsp" %>

   và

   <tiles:insert page="header.jsp" />

2. Xác định các thông số trong tiêu đề - như tiêu đề, thẻ meta, v.v. Điều này rất quan trọng, đặc biệt là theo quan điểm SEO. Với các tùy chọn tạo khuôn mẫu, bạn có thể chỉ cần xác định một trình giữ chỗ mà mỗi trang sẽ xác định. Nhưng vì vậy bạn có thể sử dụng jsp với JSTL , sử dụng <c:set>(trong trang bao gồm) và <c:out>(trong trang bao gồm)

3. Sắp xếp lại bố cục - nếu bạn muốn di chuyển breadcrumb phía trên menu hoặc hộp đăng nhập phía trên một bảng điều khiển bên cạnh khác. Nếu phần bao gồm trang (với jsp) không được tổ chức tốt, bạn có thể cần phải thay đổi từng trang trong những trường hợp như vậy. Nhưng nếu bố cục của bạn không quá phức tạp và bạn đặt những thứ phổ biến trong đầu trang / chân trang, thì không có gì phải lo lắng.

4. Kết hợp giữa các thành phần chung và nội dung cụ thể - tôi không tìm thấy vấn đề với điều này. Nếu bạn muốn sử dụng lại một số phân đoạn, hãy di chuyển nó đến một trang không bao gồm bất kỳ đầu trang / chân trang nào và đưa nó vào bất cứ nơi nào cần thiết.

5. Hiệu quả - <%@ include file="file.jsp" %>hiệu quả hơn bất kỳ thứ gì khác, vì nó được biên dịch một lần. Tất cả các tùy chọn khác được phân tích cú pháp / thực thi nhiều lần.

6. Độ phức tạp - tất cả các giải pháp không phải jsp đều yêu cầu các tệp xml bổ sung, bao gồm bổ sung, cấu hình bộ xử lý trước, v.v. Đây vừa là một đường cong học tập vừa giới thiệu thêm các điểm tiềm ẩn của lỗi. Ngoài ra, việc hỗ trợ và thay đổi trở nên tẻ nhạt hơn - bạn phải kiểm tra một số tệp / cấu hình để hiểu điều gì đang xảy ra.

7. Trình giữ chỗ - tốc độ / công cụ tự do có cung cấp gì nhiều hơn JSTL không? Trong JSTL, bạn đặt trình giữ chỗ và sử dụng mô hình (được đặt trong phạm vi yêu cầu hoặc phiên, bởi bộ điều khiển) để điền vào các trình giữ chỗ này.

Vì vậy, hãy thuyết phục tôi rằng tôi nên sử dụng bất kỳ khuôn khổ nào ở trên thay vì / ngoài JSP đơn giản.

Một vài đối số cho Velocity (Tôi chưa sử dụng Freemarker):

• Có khả năng sử dụng lại các mẫu bên ngoài ngữ cảnh web, chẳng hạn như khi gửi email
• Cú pháp ngôn ngữ mẫu của Velocity rất xa đơn giản hơn JSP EL hoặc các thư viện thẻ
• Phân tách chặt chẽ logic chế độ xem khỏi bất kỳ loại logic nào khác - không có tùy chọn khả thi nào để sử dụng thẻ scriptlet và thực hiện những việc khó chịu trong các mẫu của bạn.

Trình giữ chỗ - tốc độ / trình tự do có cung cấp gì nhiều hơn JSTL không? Trong JSTL, bạn đặt trình giữ chỗ và sử dụng mô hình (được đặt trong phạm vi yêu cầu hoặc phiên, bởi bộ điều khiển) để điền vào các trình giữ chỗ này.

Có, tài liệu tham khảo thực sự là cốt lõi của VTL:

<b>Hello $username!</b>

hoặc là

#if($listFromModel.size() > 1)
    You have many entries!
#end

Hiệu quả - <%@ include file="file.jsp" %>hiệu quả hơn bất kỳ thứ gì khác, vì nó được biên dịch một lần. Tất cả các tùy chọn khác được phân tích cú pháp / thực thi nhiều lần.

Không chắc tôi đồng ý hoặc hiểu điểm này. Velocity có một tùy chọn để lưu các mẫu vào bộ nhớ cache, có nghĩa là cây cú pháp trừu tượng mà chúng được phân tích cú pháp sẽ được lưu vào bộ nhớ cache thay vì đọc từ đĩa mỗi lần. Dù bằng cách nào (và tôi không có con số chắc chắn cho việc này), Velocity luôn cảm thấy nhanh đối với tôi.

Sắp xếp lại bố cục - nếu bạn muốn di chuyển breadcrumb phía trên menu hoặc hộp đăng nhập phía trên một bảng điều khiển bên cạnh khác. Nếu phần bao gồm trang (với jsp) không được tổ chức tốt, bạn có thể cần phải thay đổi từng trang trong những trường hợp như vậy. Nhưng nếu bố cục của bạn không quá phức tạp và bạn đặt những thứ phổ biến trong đầu trang / chân trang, thì không có gì phải lo lắng.

Sự khác biệt là, với cách tiếp cận JSP, bạn sẽ không tổ chức lại bố cục này trong mọi tệp JSP sử dụng cùng một đầu trang / chân trang? Tiles và SiteMesh cho phép bạn chỉ định một trang bố cục cơ sở (JSP, mẫu Velocity, v.v. - cả hai đều là khuôn khổ JSP ở trung tâm của chúng) nơi bạn có thể chỉ định bất cứ thứ gì bạn muốn và sau đó chỉ cần ủy quyền cho một phân đoạn / mẫu "nội dung" cho nội dung chính . Điều này có nghĩa là sẽ chỉ có một tệp để chuyển tiêu đề vào.

Sự lựa chọn giữa jsp:includevà Tiles / Sitemesh / etc là sự lựa chọn giữa sự đơn giản và sức mạnh mà các nhà phát triển luôn phải đối mặt. Chắc chắn, nếu bạn chỉ có một vài tệp hoặc không mong đợi bố cục của mình thay đổi thường xuyên, thì chỉ cần sử dụng jstlvà jsp:include.

Nhưng các ứng dụng có cách phát triển theo từng bước và khó có thể biện minh cho việc "ngừng phát triển mới và trang bị thêm (hoặc một số giải pháp khác) để chúng tôi có thể khắc phục các sự cố trong tương lai dễ dàng hơn" , điều này là bắt buộc nếu bạn không sử dụng giải pháp phức tạp khi bắt đầu.

Nếu bạn chắc chắn rằng ứng dụng của mình sẽ luôn đơn giản hoặc bạn có thể đặt một số điểm chuẩn về độ phức tạp của ứng dụng mà sau đó bạn sẽ tích hợp một trong những giải pháp phức tạp hơn, thì tôi khuyên bạn không nên sử dụng gạch / v.v. Nếu không, hãy sử dụng nó ngay từ đầu.

Tôi sẽ không thuyết phục bạn sử dụng các công nghệ khác. Đối với tất cả những gì tôi biết mọi người chỉ nên sử dụng JSP nếu nó phù hợp với họ.

Tôi chủ yếu làm việc với Spring MVC và tôi thấy JSP 2+ kết hợp với SiteMesh là sự kết hợp hoàn hảo.

SiteMesh 2/3

Cung cấp trình trang trí để áp dụng cho các khung nhìn chủ yếu giống như các công việc kế thừa trong các công cụ tạo khuôn mẫu khác. Tính năng như vậy là không thể tưởng tượng để hoạt động mà không có ngày nay.

JSP 2+

Những người tuyên bố rằng JSP sẽ khó tránh mã Java trong các mẫu là không có thật. Bạn không nên làm điều đó và với phiên bản này thì không cần thiết phải làm như vậy. Phiên bản 2 hỗ trợ các phương thức gọi bằng EL, đây là một lợi thế lớn so với các phiên bản trước.

Với các thẻ JSTL, mã của bạn sẽ trông giống như HTML nên ít khó xử hơn. Spring hỗ trợ rất nhiều cho JSP thông qua các taglibs rất mạnh mẽ.

Các taglibs cũng dễ dàng mở rộng nên việc tùy chỉnh môi trường của riêng bạn thật dễ dàng.

Một trong những đối số tốt nhất cho các chuỗi (không có trong danh sách của bạn, nhưng tôi sẽ chỉ đề cập đến nó) phản đối việc sử dụng JSP là việc biên dịch được tích hợp với trình thông dịch thay vì được ủy quyền cho trình biên dịch JSP. Điều này có nghĩa là một trong những điều khó chịu nhất mà tôi gặp phải với JSF 1.1 - phải thay đổi thuộc tính id trên một thẻ JSF xung quanh khi lưu thay đổi để công cụ thời gian chạy phát hiện ra thay đổi - đã biến mất, đưa ra lưu- in-editor, reload-in-browser cycle back, cùng với các thông báo lỗi tốt hơn nhiều.

Một công nghệ xem tốt loại bỏ hầu hết và hầu hết các câu lệnh điều kiện if / switch / anoying, đơn giản bao gồm không. Sử dụng công nghệ chế độ xem 'phức tạp' dẫn đến một ứng dụng 'đơn giản'.

Bạn đã không cung cấp thông tin về các ứng dụng cụ thể của mình. Ví dụ: tôi không sử dụng JSP chỉ vì một số lý do:

Thật khó để tránh sử dụng mã Java trong các mẫu JSP, do đó, khái niệm của bạn về Chế độ xem thuần túy bị phá vỡ và kết quả là bạn sẽ gặp khó khăn để duy trì mã ở một số nơi như chế độ xem và bộ điều khiển

JSP tự động tạo ngữ cảnh JSP để thiết lập một phiên. Tôi có thể muốn tránh nó, tuy nhiên nếu các ứng dụng của bạn luôn sử dụng phiên thì đó có thể không phải là vấn đề đối với bạn

JSP yêu cầu biên dịch và nếu hệ thống đích không có trình biên dịch Java, bất kỳ chỉnh sửa nhỏ nào sẽ yêu cầu sử dụng hệ thống khác và sau đó triển khai lại

Công cụ JSP tối thiểu là khoảng 500k bytecode cộng với JSTL, vì vậy nó có thể không phù hợp với các hệ thống nhúng

Công cụ mẫu có thể tạo ra các loại nội dung khác nhau của cùng một mô hình, chẳng hạn như tải trọng JSON, trang web, nội dung e-mail, CSV, v.v.

Lập trình viên không phải Java có thể gặp khó khăn khi làm việc với các mẫu JSP, khi những người không phải là kỹ thuật không bao giờ gặp khó khăn khi sửa đổi các mẫu thông thường.

Tôi đã hỏi câu hỏi tương tự cách đây khá lâu và kết thúc bằng cách viết khung công tác của tôi (chắc chắn dựa trên công cụ mẫu) mà không có tất cả các nhược điểm mà tôi thấy trong các giải pháp khác. Không cần phải nói nó là khoảng 100k mã byte.

Tôi nhận ra rằng điều này xuất hiện như một câu trả lời thông minh, nhưng sự thật của nó là, nếu bạn không thấy bất kỳ lợi ích nào khi sử dụng tạo khuôn mẫu trên mã trong dự án hiện tại của mình, có thể là do trong dự án hiện tại của bạn, không có .

Một phần của nó là về quy mô. Bạn có thể nghĩ rằng bao gồm mạnh mẽ như giả sử sitemesh, và điều đó chắc chắn đúng, ít nhất là đối với một số lượng nhỏ trang (tôi có thể nói là khoảng 100), nhưng nếu bạn có vài nghìn trang thì nó bắt đầu trở nên không thể quản lý được. (Vì vậy, đối với eBay thì không cần thiết, đối với Salesforce thì có lẽ là như vậy)

Ngoài ra, như đã được đề cập trước đây, freemarker và tốc độ không phải là servlet cụ thể. bạn có thể sử dụng chúng cho mọi thứ (mẫu thư, tài liệu ngoại tuyến, v.v.). Bạn không cần một thùng chứa Servlet để sử dụng freemarker hoặc speed.

Cuối cùng, điểm 5 của bạn chỉ đúng một phần. Nó được biên dịch mỗi khi nó được truy cập nếu nó chưa được như vậy. Điều này có nghĩa là bất cứ khi nào bạn thay đổi điều gì đó, bạn cần nhớ xóa thư mục "work" vùng chứa servlet của mình, để nó biên dịch lại JSP. Điều này là không cần thiết với một công cụ tạo khuôn mẫu.

TL; DR Templaing engine được viết để giải quyết một số thiếu sót (nhận thức được hoặc thực tế) của JSP + JSTL. Việc bạn có nên sử dụng chúng hay không hoàn toàn phụ thuộc vào yêu cầu của bạn và quy mô dự án của bạn.