Comments on: What’s up with JSR168? http://www.subbu.org/blog/2005/10/whats-up-with-jsr168 Wed, 08 Feb 2012 05:16:45 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Kumar Reddy http://www.subbu.org/blog/2005/10/whats-up-with-jsr168/comment-page-1#comment-70 Kumar Reddy Thu, 20 Oct 2005 06:27:54 +0000 http://wp.subbu.org/2005/10/whats-up-with-jsr168/#comment-70 Subbu,<br /><br />        I read your article with very keen interest. I believe I was in my final Year of Engineering graduation, when this JSR 168 specification is released. At that time, I Was very ignorant about the portlets, except the known fact that, <strong>"A portlet is kind of servlet". </strong>The topic i.e. discussed here is little bit way beyond my imagination and understanding, even since; I was working on weblogic portals for the past 13 months.<br /><br /> Developing portal applications with framework like weblogic (and some other) is an easy work. We developed a complex web application (<strong>2 page flows, more than 35 jsp pages and 2 web services</strong>) on Weblogic Portal (<strong>one portlet Total application</strong>). The difficulty level to develop the application with the framework support is so simple, it is matter of drag and drop the controller (Develop the views, implement the navigation flow and business logic) on the respective portlet. But, to implement the same in the basic portlet interface, It would have been so frustrating and tiresome. And it is even foolish to implement everything under one method processAction. Ofcourse, it is not guaranteed, that application developed in one framework, works in another.<br /><br /> Anyway, most of the frameworks have implemented portlet specification in their own way, they have given the portlets the MVC support to manage the controller tasks, the navigational flow and business logic and the same happened with the interportlet communications too. And in future most other features will also be implemented in a proprietary way.(The same happened to the Servlets API. No advancement has been made in API to support the controller tasks and navigations, which helped the open source frameworks to pop up to handle these tasks)<br /><br /> Why is that, a Java equivalent API is needed for the portlet API for interportlet communication?(as frameworks have already implemented it)<br /> In fragmentation, you once said, "<strong>There are several other features that portlet developers need</strong>". May I know, what are those? I am really not aware of it.<br /><br /> Please pardon me, if my questions are out of scope.<br /><br /> Cheers,<br /> Kumar Reddy. Subbu,

       I read your article with very keen interest. I believe I was in my final Year of Engineering graduation, when this JSR 168 specification is released. At that time, I Was very ignorant about the portlets, except the known fact that, “A portlet is kind of servlet”. The topic i.e. discussed here is little bit way beyond my imagination and understanding, even since; I was working on weblogic portals for the past 13 months.

Developing portal applications with framework like weblogic (and some other) is an easy work. We developed a complex web application (2 page flows, more than 35 jsp pages and 2 web services) on Weblogic Portal (one portlet Total application). The difficulty level to develop the application with the framework support is so simple, it is matter of drag and drop the controller (Develop the views, implement the navigation flow and business logic) on the respective portlet. But, to implement the same in the basic portlet interface, It would have been so frustrating and tiresome. And it is even foolish to implement everything under one method processAction. Ofcourse, it is not guaranteed, that application developed in one framework, works in another.

Anyway, most of the frameworks have implemented portlet specification in their own way, they have given the portlets the MVC support to manage the controller tasks, the navigational flow and business logic and the same happened with the interportlet communications too. And in future most other features will also be implemented in a proprietary way.(The same happened to the Servlets API. No advancement has been made in API to support the controller tasks and navigations, which helped the open source frameworks to pop up to handle these tasks)

Why is that, a Java equivalent API is needed for the portlet API for interportlet communication?(as frameworks have already implemented it)

In fragmentation, you once said, “There are several other features that portlet developers need“. May I know, what are those? I am really not aware of it.

Please pardon me, if my questions are out of scope.

Cheers,
Kumar Reddy.

]]>