The portlet API spec (JSR 168) is a piece of good work, but once you want to do something out of the ordinary with a portlet, it feels a bit...limited. Perhaps it depends on what portal engine you're using, but I'd like to share some stuff I've noticed with session variables.
A portlet sitting in one page needs to know on what portal page it is used - it needs to know the name of the portal page or the name of the navigation item / menu item the user clicked so that the portlet may show dynamic content based on that. If this is possible, I could use the same portlet instance on several portal pages.
I know, maybe portlets shouldn't be aware of where they are used, be it a mobile phone, digital TV-box or in a java portal, but I sure would like to get some more information out of the portal context.
My first thought was - the session object. I can extend the portal navigation or the portal frame (which is just a JSP page) and add code to it that sets the name of the current page or the menu item the user clicked in a session variable. Problem is that it seems impossible for a JSR 168 portlet to get to the Session object of the portal. Since the portal and the portlet are two separate web applications, this is maybe as it should be, but even so...
Then I had a quick look at the portal context object to see if I could add a property to the context from the portal framework, then read it from the portlet, but it seems impossible without changing some of the portal code that I'm not sure I want to (or can) do.
So, final option seems to be to store the name of the selected portal page in the database, using the username as key, then read it from the database in the portlet. Not the most effective solution, but I can't find any other way to do this.