2009-05-08 28 views
30

Tôi đang xem xét phát triển một ứng dụng như các portlet, được tích hợp trong cổng Web Liferay. Có bất kỳ hạn chế hoặc hạn chế đáng kể nào trong việc phát triển một ứng dụng như vậy, trái với việc phát triển một ứng dụng web thông thường bằng cách sử dụng khung công tác Spring không?Những hạn chế/bất lợi của việc phát triển các portlet cho Liferay

Liferay dường như yêu cầu tất cả nội dung được thêm dưới dạng portlet. Một tùy chọn khác mà tôi cho là sử dụng Liferay chỉ cho một số phần của ứng dụng và thêm các liên kết bên ngoài vào nội dung tự phát triển khác, được phát triển như một ứng dụng web thông thường. Tuy nhiên, điều đó sẽ tạo ra nhu cầu của nhiều cơ chế xác thực người dùng và một số loại xác thực chéo giữa Liferay và ứng dụng web khác.

Cách nào tốt nhất để đi?

Trả lời

30

(Disclaimer: Tôi là một trong các nhà phát triển Liferay)

Tôi nghĩ rằng cả hai lựa chọn là tốt tùy thuộc vào nhu cầu của bạn. Nếu bạn có kinh nghiệm trước đây phát triển các ứng dụng web độc lập nhưng không có kinh nghiệm phát triển các portlet, thì việc chọn các ứng dụng cũ sẽ giúp bạn bắt đầu nhanh hơn. Những hạn chế sẽ là bạn sẽ phải thực hiện hệ thống quyền và người dùng của riêng bạn và sẽ không thể tận dụng các dịch vụ cổng thông tin được cung cấp bởi Liferay. Nếu bạn quyết định sử dụng phương án này, lưu ý rằng bạn có thể triển khai các tệp WAR thông thường đến Liferay và nó sẽ tự động tạo một portlet đơn giản sử dụng khung nội tuyến để hiển thị ứng dụng của bạn. Điều này sẽ cho phép bạn đặt ứng dụng độc lập cùng với các portlet trong các trang của Liferay.

Phát triển một portlet cho Liferay bắt đầu trả hết khi bạn bắt đầu tận dụng các dịch vụ cổng mà nó cung cấp. Để bắt đầu bằng cách phát triển một portlet, bạn có thể quên việc phát triển hệ thống người dùng của riêng bạn và sử dụng hệ thống mà Liferay cung cấp (điều này khá mạnh). Bạn cũng có thể sử dụng các dịch vụ khác như quyền, nhận xét, gắn thẻ, phân loại, phân tích dữ liệu, v.v. cho phép bạn phát triển ứng dụng khá hoàn chỉnh trong thời gian ngắn hơn. Hạn chế là lần đầu tiên bạn làm điều này bạn sẽ phải học một số điều mới, nhưng lần thứ hai bạn sẽ đi nhanh hơn nhiều.

Tôi hy vọng điều đó sẽ hữu ích.

3

Tôi luôn nghĩ rằng Cổng thông tin như Liferay phải được coi là giống như cơ sở hạ tầng được chia sẻ. Chúng cung cấp một cách phổ biến để truy cập các ứng dụng, dịch vụ chia sẻ (ví dụ: xác thực) và cách triển khai chuẩn, nhưng với chi phí hiệu suất.

Nếu bạn có ý định triển khai nhiều hơn chỉ ứng dụng này vào Cổng thì, có, nó có thể phù hợp vì bạn sẽ tiết kiệm thời gian/chi phí không phải phát triển các dịch vụ được chia sẻ lần thứ hai. Và các ứng dụng tiếp theo sẽ trông và hành xử theo cách tương tự như thế này.

Tuy nhiên, nếu đây là ứng dụng duy nhất được triển khai thì chi phí của Cổng không thực sự đáng giá và bạn nên sử dụng ứng dụng web thông thường hơn.

+0

Tôi hy vọng nếu họ thực sự là các dịch vụ 'chia sẻ', bạn sẽ không phải viết chúng lần thứ hai. Sẽ có một số nỗ lực tích hợp, nhưng nó sẽ nhỏ hơn nhiều so với thực hiện nó lần thứ hai. – digitaljoel

0

Liferay có chức năng CMS và có thể tích hợp với các nền tảng CMS bên ngoài như Alfresco.

27

Tôi đã sử dụng Liferay trong khoảng 2 năm nay cho một ứng dụng nội bộ. Chúng tôi đã cùng thảo luận nhiều lần trong suốt chu trình phát triển trước khi phát hành lần đầu tiên. Chúng tôi đã phải chiến đấu Liferay vài lần, đôi khi vì thiếu kiến ​​thức của chúng tôi, đôi khi vì môi trường portlet, và đôi khi vì Liferay.

Nếu bạn muốn tùy chọn bố cục cho nhiều ứng dụng mà bạn có thể nhận được từ một cổng, thì bạn chắc chắn nên sử dụng Liferay. Nếu bạn đang viết một ứng dụng duy nhất, thì có lẽ tôi sẽ không sử dụng Liferay.Tôi nghĩ rằng một lai của một số Liferay và một số không phải là đến nay là lựa chọn tồi tệ nhất.

Có lẽ chúng tôi không tận dụng Liferay với khả năng tối đa của nó, nhưng nếu đây là ứng dụng Liferay đầu tiên của bạn, thì rất có thể bạn sẽ không phải vì đường cong học tập. Ban đầu chúng tôi hy vọng có nhiều portlet khác nhau cho các khía cạnh khác nhau của ứng dụng, nhưng do thiếu các cơ chế giao tiếp giữa các portlet tốt trong quá trình phát triển (trước JSR-286), chúng tôi đã viết một ứng dụng duy nhất. Bây giờ chúng tôi đã kết thúc trong chiếc thuyền đó, tôi ước rằng chúng tôi đã đi mà không có Liferay vì tất cả những gì chúng tôi đang thực sự sử dụng là một số khả năng quản lý người dùng.

Chúng tôi sử dụng JSF và facelets (cả hai công nghệ mới cho chúng tôi, vì vậy nỗi đau có thể là tự phát sinh) và trong khi chúng tôi đã nhận được tốt hơn nó, nó có vẻ như có một vài hoops chúng tôi đã phải nhảy qua theo thứ tự để làm cho nó hoạt động chính xác trong một portlet; Những thứ không phải xảy ra trong một môi trường ứng dụng web thông thường. Đối với nhiều khuôn khổ, có vẻ như hỗ trợ portlet là một suy nghĩ. Điều này rõ ràng không phải là Liferay cụ thể, nó chỉ là một sản phẩm phụ làm việc trong môi trường portlet.

Trong ứng dụng web sử dụng Spring MVC, Struts, Faces, Wicket, bất cứ điều gì, bạn sẽ có nhiều quyền kiểm soát hơn mọi thứ, nhưng cũng chịu trách nhiệm triển khai nhiều nội dung hơn.

Trong một portlet, bạn sẽ tuân theo các điều khoản của JSR-168 và/hoặc JSR-286. Vùng chứa cổng thông tin sẽ cung cấp một số chức năng cho bạn, như xác thực người dùng, nhưng IMO, toàn bộ cổng thông tin để xác thực người dùng là quá nặng. Tôi thấy sức mạnh của cổng thông tin đang cho phép người dùng tùy chỉnh chế độ xem của nhiều ứng dụng, không hiển thị một ứng dụng đơn lẻ.

Bạn nên xem lại thông số kỹ thuật có liên quan đến portlet và xem liệu nó có phù hợp với nhu cầu của bạn hay không.

http://developers.sun.com/portalserver/reference/techart/jsr168/

7

Liferay và các portlet nói chung là tuyệt vời cho một lớp học rất cụ thể của ứng dụng. Nếu bạn đang làm việc cho một bộ phận CNTT và cần phải kết hợp các ứng dụng cho hoặc bởi một số phòng ban thì các portlet sẽ là con đường để đi. Về lý thuyết bạn có thể thả các portlet từ những người bán hàng khác nhau và tất cả họ sẽ sống hài hòa bên trong cùng một môi trường.

Tuy nhiên nếu bạn đang xây dựng một ứng dụng mà là bất cứ điều nào sau đây

1) tạo ra hoàn toàn bởi một nhóm đơn 2) có một nguồn duy nhất cho các yêu cầu 3) có những yêu cầu mà không phải là một tập hợp con các tính năng có sẵn trong vùng chứa portlet. 4) có một nhà thiết kế đồ họa không sẵn sàng sống trong giới hạn các ứng dụng kiểu cổng thông tin.

sau đó gắn bó với thứ gì đó như Mùa xuân sẽ là cách để đi.

Mùa xuân và nhiều tiểu dự án cung cấp rất nhiều dịch vụ và cơ sở hạ tầng được cung cấp bởi các portlet nhưng chúng được cung cấp theo cách cởi mở và linh hoạt hơn. Bạn có thể chọn và chọn những gì bạn muốn.

Portlets thực hiện rất nhiều quyết định thiết kế cho bạn về xác thực và ủy quyền, điều hướng và bố cục. Nếu các kế hoạch bạn có cho ứng dụng của bạn nằm ngoài các quyết định đó, bạn sẽ dành rất nhiều thời gian để tạo các cách giải quyết để thử và làm cho nó hoạt động theo ý bạn muốn.

12

Liferay là một hệ thống cực kỳ mạnh mẽ, có rất nhiều dịch vụ và ứng dụng sẵn sàng thực hiện nhưng nhược điểm lớn nhất là thiếu tài liệu. Nó không thể biết tất cả mọi thứ chỉ cần nhìn vào mã, Vì vậy, theo ý kiến ​​của tôi nếu bạn không có chuyên môn không đi cho Liferay.

+17

+1 vì thiếu tài liệu, Liferay là tài liệu khủng khiếp. – Jakub

0

Man, hãy xem giải pháp này Netbeans IDE + PoralPack3.0 plugin + Liferay 5.2 bundle. Gói Portal ở đây giúp bạn bằng cách cung cấp một trình soạn thảo GUI đẹp cho tệp service.xml, nơi bạn có thể định nghĩa các thực thể hoặc cấu trúc cơ sở dữ liệu và từ cùng một GUI, bạn có thể tạo mã dịch vụ có thể được sử dụng bên trong portlet của bạn.

Để biết thêm thông kiểm tra liên kết dưới đây đưa ra: http://www.liferay.com/web/satyaranjan/blog/-/blogs/portal-pack-:-write-database-portlet-using-service-builder-plug-in

+0

Nước ép của Liferay là - 1. bạn có thể tập trung vào logic kinh doanh thuần túy để lại tất cả những thứ cấp thấp cho LR; 2. Tất cả các chức năng LR đều có thể tùy chỉnh và bạn có thể tạo các portlet hoàn toàn tương thích của riêng mình. –

6

Mọi người, xin đừng coi đây là trolling/rực. Đây là điều mà tôi cảm thấy cộng đồng Liferay nên giải quyết và mọi người nghĩ đến việc sử dụng Liferay nên biết.

Bất lợi: Không có tài liệu. Không có gì thậm chí từ xa như ví dụ, tài liệu về Hibernate. Chỉ cần một javadock rỗng (không có ý kiến ​​trong mã), một số câu hỏi đã trả lời trong diễn đàn và sách cho các phiên bản cũ (vô ích).

+1

cũng - có câu trả lời này đã được một tuổi, tôi đồng ý một chút, nhưng nếu bạn làm theo các nỗ lực tài liệu, điều này đã thay đổi rất nhiều trong thời gian này. Tài liệu trên https://www.liferay.com/de/documentation được tân trang lại, wiki và diễn đàn khá tích cực. Đó là một hệ thống phức tạp, tài liệu luôn có thể được cải thiện, nhưng nó cũng đã làm rất nhiều. Vấn đề là bạn cần phải hiểu cách nhiều hơn trong hibernate nếu bạn nhận được vào phát triển và các chi tiết khác. Có, không có javadoc - nhưng mã tuân theo các tiêu chuẩn mã hóa nghiêm ngặt, do đó, có cách để đọc và hiểu nó nếu bạn quen với điều này. –

+4

Ngay cả khi mã tuân theo các tiêu chuẩn mã hóa nghiêm ngặt, tổng số thiếu Javadoc trên bất kỳ hệ thống nào phản ánh quản lý và kiến ​​trúc kém, hoặc (theo cách khác) cơ sở mã không được thiết kế để sửa đổi hoặc hiểu rõ. – jevon