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