What aspects of portlet development can we adopt prior to implementing a portal platform?
Currently my team develops online forms using Java servlets and fairly simple HTML or Flex front-ends, with each form deployed as a stand-alone EAR. The plan is to shift our entire site to portal servers and develop new UIs for interactive content (like开发者_运维问答 forms) using JSF, but for the time being we still have forms to develop for deployment on the old WAS 6.1 servers. Obviously JSF is something we can start to adopt right away, but I'd also like the team to get some experience in upcoming projects that will help us when we start developing portlet-based projects in the future.
It's entirely possible that we'll end up rewriting each form after the portal platform is implemented, so I'm not necessarily looking for ways to structure our code so that it can be adapted for portal use. Instead I'd like to focus on any relevant design patterns, technologies, libraries, APIs etc. that we may not be using for our servlets at present, but which we can adopt without requiring any changes to our old WAS 6.1 servers (and without taking a lot of time and effort to shoe-horn in to a servlet-based system).
I'm not entirely sure if this helps, but for example Liferay portal has a lot of portlets (or wrappers) for different languages (even php). There is also an approach how to implement a portlet adopting Flex (here, though it might need to be adapted since it was written for an earlier version of Liferay). Since you can use a portlet alongside with EE technology, it might not be possible to slowly migrate your apps into portlets one by one.
精彩评论