I have made available a very basic example application for the PortletWork framework. It does not do much besides supporting different portlet modes, some form submitting, and example of Spring support, but it can nevertheless aid as a template for PortletWork application development.
Yesterday, I tried to deploy the sample application to different portlet containers. Earlier, I have successfully deployed it to WebSphere Portal Server 5.x, JetSpeed2, Pluto and JBoss Portal. This time, Liferay and Gridsphere were the targets.
Deployment to Liferay quite straight forward once I got the server up and running, and did not require any additional descriptors. Just invoke an ant task, and off you go.
Gridsphere, however, was a bit more tedious. After a while, I found this resource describing the additional steps needed to get a JSR168 portlet up and running in Gridsphere. After adding the extra descriptors and library, everything was up and running.
Tuesday, November 22, 2005
Thursday, November 03, 2005
PortletWork 1.0-beta-1: JSR168/XWork/WebWork framework
I finally decided to publish PortletWork, which is a JSR168 portlet development framework I've been developing for about a year.
PortletWork is a framework built on XWork/WebWork and JSR168. It is basically a dispatcher for XWork in a Portlet Container, in addition to some re-use of the WebWork JSP tag libraries and interceptors. Only minor changes in the xwork.xml configuration file, and one custom JSP taglib (due to the special handling of URLs in a portlet container) is required to start using PortletWork. It currently runs with XWork 1.0.5 and WebWork 2.1.7.
The motivation for making PortletWork was not only to ease the migration of existing web applications to a portlet environment, but also to provide a solid framework for building "native" portlet applications, utilizing the core concepts of JSR168 such as modes, phases, preferences etc. It is possible, for instance, to map XWork package namespaces to portlet modes, and to have multiple portlets in a portlet application using different package namespaces. This makes it trivial to group actions into a logical structure of packages.
Some of the remaining tasks before 1.0 final is documentation (surprise, surprise), and releasing a proper example application that can be used as a template for development.
There is a maven generate site with some documentation at http://boss.bekk.no/boss/portletwork. The project itself is published on SourceForge at http://www.sf.net/projects/portletwork.
All feedback is appreciated.
PortletWork is a framework built on XWork/WebWork and JSR168. It is basically a dispatcher for XWork in a Portlet Container, in addition to some re-use of the WebWork JSP tag libraries and interceptors. Only minor changes in the xwork.xml configuration file, and one custom JSP taglib (due to the special handling of URLs in a portlet container) is required to start using PortletWork. It currently runs with XWork 1.0.5 and WebWork 2.1.7.
The motivation for making PortletWork was not only to ease the migration of existing web applications to a portlet environment, but also to provide a solid framework for building "native" portlet applications, utilizing the core concepts of JSR168 such as modes, phases, preferences etc. It is possible, for instance, to map XWork package namespaces to portlet modes, and to have multiple portlets in a portlet application using different package namespaces. This makes it trivial to group actions into a logical structure of packages.
Some of the remaining tasks before 1.0 final is documentation (surprise, surprise), and releasing a proper example application that can be used as a template for development.
There is a maven generate site with some documentation at http://boss.bekk.no/boss/portletwork. The project itself is published on SourceForge at http://www.sf.net/projects/portletwork.
All feedback is appreciated.
Subscribe to:
Posts (Atom)