There is some interesting speculation about the future of JSR-168 going on at the Portlets Yahoo! Group. IMO (which is a redundant thing to say because this whole blog is My Opinion), I don’t think the spec is going away by any means. But at the same time, it seems that the entire industry has come to recognize it as the “lowest common denominator” of portlet functionality. In terms of features, it fails to specify portlet-to-portlet communication APIs among several other things. But worst of all, it’s designed with the presumption that the portlets will always run inside the portal container. Humph.
The future of JSR-168
There is some interesting speculation about the future of JSR-168 going on at the Portlets Yahoo! Group. IMO (which is a redundant thing to say because this whole blog is My Opinion), I don’t think the spec is going away by any means. But at the same time, it seems that the entire industry has […]
One reply on “The future of JSR-168”
I stand corrected (somewhat). There are ways to communicate across portlets using JSR-168. However, the portlets must be running in the same web application and it appears as though you need to make a complete page refresh in order to accomplish this.
I’ve found that allowing portlets to communicate with one another across WARs and without a complete page refresh is necessary in some — if not many — situations. Plumtree offers alternatives like the PCC (Portlet Communications Component) to help you work around this. You can also apply techniques similar to those used in AJaX. Plumtree has lumped these techniques together under the umbrella term Adaptive Portlets. More on this later. . . .