Time to time I receive questions regarding complexity of the Portlet components. In this post, I'll try to add my 2 cents to discussions regarding complexity related to developing portals, and specifically custom portlet development.
Around 10-12 years back when I started developing applications using JSPs and Servlets, it was difficult because of ad hoc ways we followed....using different design patterns. Then, we moved on to using Struts web framework, and web application development became quite easy. Along the way came many more web frameworks with their own set of unique features.
Portlets are a different beast because of their unique lifecycle. Their lifecycle is complex only as long as you don't understand it. After that it is like a walk in the park. It follow the PRG (Post-Redirect-Get) pattern. If you know PRG, you can quickly correlate it with portlet lifecycle. What Portlets can do is something quite amazing....showing windowed applications in a single page (content aggregation) with well defined mechanisms for communication (inter-portlet communication) and built-in feature for personalizing each such windowed application in the page.
If I compare Portlets to GWT, I find GWT comparatively more complex than Portlets....compile-time code translation, deferred binding, using Gin for dependency injection, MVP architecture that talks about activities and places, and so on. If I look at Flex, it's also similar to GWT in terms of complexity. Singling out Portlets as a complex solution to building portals is not justified. If you're using Spring Portlet MVC (which has the distinction of the only MVC framework designed specifically for building Portlets) you'll find that it results in a very intuitive design of your custom portlets. Chapter 7 and 8 of Portlets in Action demonstrate that you can quickly put your Spring skills in portlet development in no time. Testing of portlets is also simplified if you are using Spring's TestContext framework for unit and integration testing.
Around 10-12 years back when I started developing applications using JSPs and Servlets, it was difficult because of ad hoc ways we followed....using different design patterns. Then, we moved on to using Struts web framework, and web application development became quite easy. Along the way came many more web frameworks with their own set of unique features.
Portlets are a different beast because of their unique lifecycle. Their lifecycle is complex only as long as you don't understand it. After that it is like a walk in the park. It follow the PRG (Post-Redirect-Get) pattern. If you know PRG, you can quickly correlate it with portlet lifecycle. What Portlets can do is something quite amazing....showing windowed applications in a single page (content aggregation) with well defined mechanisms for communication (inter-portlet communication) and built-in feature for personalizing each such windowed application in the page.
If I compare Portlets to GWT, I find GWT comparatively more complex than Portlets....compile-time code translation, deferred binding, using Gin for dependency injection, MVP architecture that talks about activities and places, and so on. If I look at Flex, it's also similar to GWT in terms of complexity. Singling out Portlets as a complex solution to building portals is not justified. If you're using Spring Portlet MVC (which has the distinction of the only MVC framework designed specifically for building Portlets) you'll find that it results in a very intuitive design of your custom portlets. Chapter 7 and 8 of Portlets in Action demonstrate that you can quickly put your Spring skills in portlet development in no time. Testing of portlets is also simplified if you are using Spring's TestContext framework for unit and integration testing.
No comments:
Post a Comment