tags:

views:

126

answers:

1

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 interaction 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?

+2  A: 

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.

ewernli
Yes it appears that the portlet spec is designed for the heavyweight implementation, with no option for the lightweight.We have a number of portlets that do stuff, and live as portlets ought. However the majority are display only, and most of those are a view on a common model determined by the page request parameters.
John Smith
I wouldn't qualify that of heavyweight/lightweight. The model provides full isolation between portlet instances. You would like less isolation and able to "group" them so that they can share information. That's the same issue with inter-portlet communication which isn't standardized yet, or maybe in portlet API 2.0. Those are different design goals.
ewernli
You can maybe package your model in a service layer that you deploy in shared class loader. This way all portlets instance share the same classes for the model and you can provide caching, etc. Just an idea.
ewernli