The portlet API deos not provide any reference to the enclosing servlet request and response objects. I know it is not the preferred model of interact开发者_JAVA百科ion with the user, but it seems draconian to remove all access.
I understand that for portlet driven interaction with the user, you want to use portlet URLs, and let the portlet container manage all the complexity.
However if you have a number of portlets which are basically showing variants of the same data, it makes sense for them to be able to use the enclosing request to drive the data.
We ended up using using a Liferay specific call to get the request, and it all seems to work as we wish.
However I do feel the guilt.
So my question really is, is there an underlying deep reason for the prohibition, or is it just to enforce the authors view of the API environment?
The portlet doesn't run right into the Servlet container, but rather what is called a Portlet container.
You should be able to access to the corresponding information, PortletRequest
, PortletResponse
, and PortletContext
.
The reason is that two instances of the same portlet can run next to each other in the same page, but still be isolated with their own lifecycle. The portal will "multiplex" that transparently for you, and it will convert from the servlet world to the portlet world. Portlet bridges are also available to develop portlets with non-portlet technologies (e.g. JSF). I agree that all this is usually (very) complicated to use (because of the many frameworks and implementations available), but when you think of how it works conceptually, it's quite nice.
The exact details will depend on the technologies you chose to develop the portlet. But I feel like there should be a way to do what you want using the portlet API.
精彩评论