2009-05-08 7 views
30

Liferay 포털에 통합하기 위해 포틀릿으로 애플리케이션을 개발할 것을 고려하고 있습니다. Spring 프레임 워크를 사용하여 일반적인 웹 애플리케이션을 개발하는 것과는 대조적으로 그러한 애플리케이션을 개발할 때 중대한 단점이나 제한이 있습니까?Liferay 용 포틀릿 개발의 제한/단점

Liferay는 모든 내용이 포틀릿으로 추가되도록 요구하는 것으로 보입니다. 필자가 생각해 볼 수있는 또 다른 옵션은 응용 프로그램의 일부분 만 Liferay를 사용하고 일반 웹 응용 프로그램으로 개발 된 다른 자체 개발 컨텐트에 외부 링크를 추가하는 것입니다. 그러나 Liferay와 다른 웹 응용 프로그램간에 여러 사용자 인증 메커니즘과 일종의 교차 사이트 인증이 필요합니다.

가장 좋은 방법은 무엇입니까?

답변

30

(면책 조항 : 나는을 Liferay의 개발자 중 한거야)

나는 두 옵션은 필요에 따라 좋은 생각합니다. 이전에 독립형 웹 애플리케이션 개발 경험이 있지만 포틀릿 개발 경험이 없다면 전자를 선택하면 더 빨리 시작할 수 있습니다. 단점은 자신의 사용자와 권한 시스템을 구현해야하고 Liferay가 제공하는 포털 서비스를 활용할 수 없다는 것입니다. 이 대안을 사용하기로 결정한 경우 일반 WAR 파일을 Liferay에 배포 할 수 있으며 iframe을 사용하여 앱을 보여주는 간단한 포틀릿을 자동으로 생성합니다. 이렇게하면 독립 실행 형 응용 프로그램을 Liferay의 페이지에 포틀릿과 함께 넣을 수 있습니다.

Liferay에 대한 포틀릿을 개발하면 그것이 제공하는 포털 서비스의 활용을 시작할 때 성과가 나타납니다. 포틀릿을 개발하여 시작하려면 자신의 사용자 시스템을 개발하는 것을 잊어 버리고 Liferay가 제공하는 것을 사용하십시오 (매우 강력합니다). 사용 권한, 주석, 태깅, 분류, 데이터 범위 지정 등과 같은 다른 서비스를 사용하여 짧은 시간 내에 완벽한 응용 프로그램을 개발할 수 있습니다. 단점은 처음으로 이것을하면 몇 가지 새로운 것을 배워야하지만, 두 번째로 빠를수록 더 빠를 것입니다.

도움이 되었기를 바랍니다.

3

나는 항상 Liferay와 같은 포털을 공유 인프라와 유사하게 생각해야합니다. 이들은 응용 프로그램, 공유 서비스 (예 : 인증) 및 표준 배포 방법에 액세스하는 일반적인 방법을 제공하지만 성능은 저하됩니다.

이 애플리케이션을 포털에 추가로 배포하려는 경우 예, 두 번째로 해당 공유 서비스를 개발하지 않아도되므로 시간/비용 절감 효과를 얻으실 수 있습니다. 후속 애플리케이션은 이와 비슷한 방식으로 보이고 동작합니다.

그러나 이것이 유일한 응용 프로그램 인 경우 포털의 오버 헤드는 그다지 가치가 없으므로 일반 웹 응용 프로그램을 사용하는 것이 좋습니다.

+0

정말 '공유 된'서비스라면 두 번째로 쓸 필요가 없기를 바랍니다. 통합 노력이 필요하지만 두 번째 구현보다 훨씬 작아야합니다. – digitaljoel

0

Liferay에는 CMS 기능이 있으며 Alfresco와 같은 외부 CMS 플랫폼과 통합 할 수 있습니다.

27

저는 Liferay를 내부 응용 프로그램으로 약 2 년 동안 사용해 왔습니다. 우리는 첫 번째 출시 이전의 개발주기 동안 여러 번 동일한 토론을 가졌습니다. 우리는 Liferay와 몇 차례 싸워야 만했습니다. 때로는 지식 자체가 부족하기 때문입니다. 때로는 포틀릿 환경 때문에, 때로는 Liferay 때문에.

포털에서 얻을 수있는 여러 응용 프로그램의 레이아웃 옵션을 원할 경우 Liferay를 사용해야합니다. 단일 응용 프로그램을 작성한다면 Liferay를 사용하지 않을 것입니다.나는 어떤 Liferay와 어떤 것의 하이브리드가 훨씬 최악의 선택이라고 생각한다.

우리는 Liferay의 기능을 최대한 활용하지는 않을 것입니다. 그러나 이것이 Liferay 앱의 첫 번째 앱이라면 학습 곡선 때문에 기회가 없을 것입니다. 우리는 처음에는 애플리케이션의 여러 측면에서 다양한 포틀릿을 원했지만 개발 중 포틀릿 간 통신 메커니즘이 부족하여 (JSR-286 이전) 단일 애플리케이션을 작성했습니다. 이제 우리가 그 보트에서 끝났기 때문에 우리가 실제로 사용하는 모든 것이 사용자 관리 기능이기 때문에 Liferay없이 사라 졌으면 좋겠습니다.

우리는 JSF와 facelets (우리에게 새로운 기술이기 때문에 통증이 스스로 가라 앉았을 수 있습니다)를 사용하고 우리가 더 잘하는 동안 순서대로 점프해야했던 것처럼 보입니다 포틀릿에서 올바르게 작동하도록합니다. 정기적 인 웹 앱 환경에서 발생하지 않아야 할 일들. 많은 프레임 워크의 경우, 포틀렛 지원은 추가 고려 사항입니다. 분명히 Liferay에만 국한된 것은 아니며, 포틀릿 환경에서 작업하는 것의 부산물 일뿐입니다.

스프링 MVC, Struts, Faces, Wicket을 사용하는 웹 응용 프로그램에서는 모든 것을 제어 할 수있을뿐만 아니라 더 많은 것들을 구현할 책임이 있습니다.

포틀릿에서 JSR-168 및/또는 JSR-286의 조건을 준수하게됩니다. 포털 컨테이너는 사용자 인증과 같은 일부 기능을 제공하지만 사용자 인증을위한 전체 포털 인 IMO는 너무 무거워요. 나는 포털의 힘으로 사용자가 하나의 응용 프로그램을 제시하지 않고 여러 응용 프로그램의보기를 사용자 정의 할 수 있음을 알게되었습니다.

포틀릿 관련 스펙을 검토하고 필요에 맞는 지 확인하십시오.

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

7

을 Liferay와 일반적으로 포틀릿 응용 프로그램의 매우 구체적인 클래스를 위해 중대하다. IT 부서에서 일하고 있고 여러 부서에서 또는 여러 부서에서 응용 프로그램을 결합해야하는 경우 포틀릿을 사용할 수 있습니다. 이론적으로 다른 벤더의 포틀릿을 드롭하면 동일한 환경 내에서 모두 조화롭게 살아납니다. 그러나

다음

1) 중 어느 하나의 팀 2)에 의해 완전히 만든 응용 프로그램을 구축하는 경우는 일부하지 않은 요구 사항 3) 요구 사항에 대한 단일 소스를 가지고 포틀릿 컨테이너에서 사용할 수있는 기능 중 하나입니다. 4) 그래픽 디자이너가 포털 스타일 응용 프로그램의 범위 내에서 기꺼이 살지 않습니다.

그러면 스프링과 같은 것을 고집하는 것이 좋습니다.

스프링 및 많은 서브 프로젝트는 포틀릿에서 제공하는 많은 공유 서비스 및 인프라를 제공하지만 개방적이고 유연한 방식으로 제공됩니다. 원하는 것을 골라 골라 낼 수 있습니다.

포틀릿은 인증 및 권한 부여, 탐색 및 레이아웃 측면에서 많은 디자인 결정을 내립니다. 귀하가 귀하의 신청서에 대한 계획이 그러한 결정을 벗어난다면, 귀하가 원하는 것을하기 위해 해결 방법을 만들기 위해 많은 시간을 할애 할 것입니다.

12

Liferay는 매우 강력한 시스템으로 준비가되어있는 많은 서비스와 응용 프로그램이 있지만 가장 큰 단점은 문서가 부족하다는 것입니다. 그것은 단지 코드를 보는 모든 것을 아는 것은 불가능합니다. 제 의견으로는 Liferay에 대한 전문 지식을 갖고 있지 않으면 말입니다.

+17

+1 문서가 없다는 이유로 Liferay는 문서 작성이 끔찍합니다. – Jakub

0

사람,이 솔루션 Netbeans IDE + PoralPack3.0 플러그인 + Liferay 5.2 번들을 확인하십시오. Portal Pack은 여기 엔티티 또는 데이터베이스 구조를 정의 할 수있는 service.xml 파일 용 멋진 GUI 편집기를 제공하며, 동일한 GUI에서 포틀릿 내부에서 사용할 수있는 서비스 코드를 생성 할 수 있습니다. 더 많은 정보는 아래 링크를 확인을 위해

는 : http://www.liferay.com/web/satyaranjan/blog/-/blogs/portal-pack-:-write-database-portlet-using-service-builder-plug-in

+0

Liferay의 주스는 - 1. 당신은 순수한 비즈니스 로직에 집중하여 LR에 모든 저급 항목을 남겨 둘 수 있습니다. 2. 모든 LR 기능을 사용자 정의 할 수 있으며 완전히 호환 가능한 포틀릿을 직접 만들 수 있습니다. –

6

모두를, 불타는/건지 러로 이것을하지 마십시오. 이것은 내가 Liferay 커뮤니티가 해결해야한다고 생각하는 것입니다. Liferay를 사용하려고 생각하는 모든 사람들은 알아야합니다.

단점 : 문서가 없습니다. 예를 들어 Hibernate의 문서화와 같이 원격으로도 불가능합니다. 그냥 빈 javadock (코드 주석 없음), 포럼 및 이전 버전 (쓸모없는)에 대한 책에서 일부 대답 질문.

+1

글쎄 -이 대답은 1 년이 지났지 만 다소 동의하지만 문서 작업을 수행하면이 기간 동안 많은 변화가있었습니다. https://www.liferay.com/de/documentation에 대한 문서가 개정되었으며, wiki 및 forum은 상당히 활성화되었습니다. 복잡한 시스템이므로 문서를 항상 개선 할 수 있지만 많은 작업을 수행했습니다. 문제는 개발 및 기타 세부 사항에 도달하면 최대 절전 모드보다 더 많은 방법을 이해해야한다는 것입니다. 예, javadoc은 없습니다. 그러나 코드는 엄격한 코딩 표준을 따르므로 익숙해지면 읽고 이해하는 방법이 있습니다. –

+4

코드가 엄격한 코딩 표준을 따르더라도 모든 시스템에서 Javadoc이 완전히 부족한 것은 잘못된 관리 및 아키텍처를 반영하거나 (또는) 코드 기반이 전혀 수정되거나 해석되지 않도록 설계되었습니다. – jevon

관련 문제