JSR-168 Summary :
Limitations of JSR-168 :
1. Inter-portlet communication
● only supported
within the same portlet application using
session attributes
● target portlets will only “see” messages during next render
request
● portlets cannot (should not) update their state during a
render request: “event” handling not really possible
session attributes
● target portlets will only “see” messages during next render
request
● portlets cannot (should not) update their state during a
render request: “event” handling not really possible
2. Serving
non-markup resources
● A portlet can
only render markup fragments
● Direct URL
access to a portlet is not possible
● Requires direct
servlet URLs for serving resource requests
outside the markup
fragment
● Might require
(session) state coordination, like for security,
between the
portlet and the direct servlet requests
3. Contributing
to <head>, setting cookies
● Javascript or
CSS can only be embedded withing the content
markup; no body onLoad
handling hooks
● No way to
optimize or prevent duplicate contributions
● The API forbids
adding cookies: only client side setting of
cookies using
javascript is possible.
4. Proper
support for common web frameworks
● A lot of web
frameworks are still primarily (or only) Servlet
API oriented
● Servlet
dispatching not supported from processAction
● Needs Portals
Bridges or similar solutions
● Separate Action
and Render request phases are difficult to
incorporate or to
migrate to
● “Unaware”
servlets only “see” the application scope session
● JSP/JSTL support
very limited:
<c:out
value=”<%= ((FooBean)renderRequest.getSession()
.getAttribute("fooBean",PortletSession.PORTLET_SCOPE))
.getBeanValue()
%>"/>
5. AJAX
● Portable
solutions only using servlets are inefficient and ugly
● Many portals do
provide native AJAX support now
● Native AJAX
support with access to the portlet environment
requires custom /
portal specific extensions
● But none of that
is endorsed by the spec.
