Tôi có một dự án mà khách hàng của tôi yêu cầu tôi sử dụng thông số kỹ thuật portlets 1.0 và Websphere Portal Server 6.0. Tôi chưa từng làm việc với các portlet trước đây nhưng những gì tôi nghe về họ luôn là những lời phê bình tồi tệ. Những lý do ngoài việc sử dụng chúng là gì? Nếu không phải lý do, tôi có thể sử dụng đối số nào để tránh chúng?Ưu điểm và nhược điểm của Java Portlets?
Những vấn đề tôi có với các portlet nhắc nhở tôi về những vấn đề tương tự như EJBs-
tôi muốn đề nghị một cái gì đó giống như Google Gadgets như Hibernate để của portlet EJB -
Portlets hấp dẫn doanh nghiệp vì lời hứa về tính linh hoạt, bạn cho phép khách hàng tinh chỉnh và sắp xếp lại các thành phần trên trang và nếu bạn chủ yếu phục vụ nội dung thì đó là phương tiện hiệu quả.
Trong cổng thông tin ý kiến của tôi rất thích hợp để tổng hợp các portlet là nội dung thuần túy, độc lập về chức năng hoặc đơn giản liên quan (ví dụ: khi bạn chọn một mục từ danh sách trong một portlet, bạn cập nhật một mục khác để hiển thị chi tiết). Portlets cũng có thể cho phép tái sử dụng, bởi vì bạn có thể cấu hình chúng thành nhiều trang/địa điểm khá đơn giản.
Trường hợp các vấn đề có thể bắt đầu là khi bạn đang cố gắng phân hủy các chức năng nghiệp vụ phức tạp bằng nhiều bước và tương tác. Trong kịch bản này xác định mức độ chi tiết của các portlet là nhiều hơn một nghệ thuật hơn là một khoa học, và cần xem xét cẩn thận các tương tác giữa các portlet.
Bạn cũng cần xem xét tính linh hoạt của giao diện người dùng. Nếu bạn có một tập hợp các khối xây dựng portlet, doanh nghiệp của bạn cần phải rõ ràng rằng họ có thể sắp xếp lại các khối đó, nhưng việc di chuyển các mục giữa các portlet liên quan đến việc viết lại. Ví dụ di chuyển nút gửi từ một portlet đến cuối trang không phải là tầm thường.
Vì vậy, trong tóm tắt, tôi đoán nó phụ thuộc vào những gì bạn đang cố gắng làm và bao nhiêu tái sử dụng bạn dự đoán của các thành phần. Nó có thể đơn giản hơn để quản lý việc tái sử dụng bằng cách tạo các thành phần kỹ thuật mà CNTT xây dựng thành các servlet, hoặc nó có thể là các portlet hoàn hảo cho doanh nghiệp của bạn. Không có câu trả lời đúng, bạn chỉ cần cẩn thận xem xét những gì bạn đang cố gắng đạt được. Nếu bạn quyết định các portlet, bạn cần phải nắm lấy vòng đời đầy đủ và tránh bất kỳ sự cám dỗ nào để làm việc xung quanh chúng, bạn có thể nhanh chóng tìm thấy mình ở một nơi tồi tệ với tất cả các chi phí và hạn chế của portlet, mà không thể nhận ra những lợi thế.
+1, chúng tôi phải đối mặt với cùng một vấn đề mà bạn mô tả ở đây – Chris
Là một người đã có một số công việc (bao gồm cả công việc hiện tại của tôi) phát triển các portlet Java, tôi muốn nói không sử dụng chúng.
Dưới đây là các vấn đề:
Nếu bạn chỉ muốn sử dụng tồn tại trước đó chức năng của cổng thông tin bạn đang lựa chọn, sau đó sử dụng một cổng thông tin.
Nếu bạn sử dụng các portlet chỉ là xây dựng một bảng điều khiển dựa trên web nhỏ, nhẹ, chỉ đọc ở nơi bạn có thể xem nhanh thông tin khác nhau, thì tốt.
Nhưng nếu bạn (hoặc nhiều khả năng cao hơn trên biểu đồ org) nghĩ về portlet như một cách để đặt một loạt các ứng dụng web khác nhau trên một trang và có tất cả "chỉ hoạt động", thì bạn đang hướng đến một thế giới bị thương. Portlets là những miền có chức năng hạn chế, độc lập, không phải là các ứng dụng web trong các ô vuông nhỏ trên một trang.
Mọi công việc dựa trên portlet của tôi đều gây ra lỗi này và không có ánh sáng ở cuối đường hầm. Là một nhà phát triển portlet, đây là danh sách nhỏ những thứ bạn thường làm trong các ứng dụng web thông thường, mà bạn không thể thực hiện một cách đáng tin cậy trong các portlet:
Portlets cảm thấy như thể chúng được thiết kế cho trạng thái phát triển web như trong giai đoạn từ giữa đến cuối thập niên 90 (trước AJAX). Nhưng chúng không phù hợp với môi trường phát triển web ngày nay (AJAX, các ứng dụng web phong phú một trang, v.v.) giả sử bạn có toàn quyền kiểm soát chu kỳ yêu cầu/phản hồi.
+1 từ tôi - câu trả lời rất hay. – duffymo