Hello! sorry for my English. I'm new using portlets.I have a problem. I'm using portlets and a websphere portal server. I have a jsp in the theme of my portal and in this jsp i call a java class to save an attribute into the session. Now using portal url generation i go to a portlet and i want to read and modify the attribute i saved before from the jsp of the theme, but I have read that the session is not shared between different applications. How can I fix this? thanks
Application scope? I think that only shares the data across portlets in a common war file, not to all portlets in the application.
Part of being a good portal developer is to think like a portal developer.
Portlets should be very much stand-alone. Some may interact at some level with other portlets, but interacting with a variable in a theme? Well, that's really pushing it.
To develop portlets, you've got to think like a portlet developer, and not like a typical servlet/JSP developer.
Maybe you could tell us why you need to do this? Maybe then we can figure out a better solution. As far as how goes, well, other than casting a PortletSession back into an HttpSession (and configuring the server to share sessions across all we apps), there's probably not much of a way. Maybe a centralized database table the theme and the portlet can read from? Eitehr way, these aren't very elegant solutions, and likely wouldn't pass an architecture review.
Now the client don�t want to use the database. My problem is they have a combobox in a jsp of the portal theme and when you change the value in the combo I have to redirect to a portlet that uses this value to make a search and after this comunication the portal has been reload and in the combo the value is not the selected one. It's very difficult to explain the problem. Thanks
Can you create a portlet that is always in the top right hand corner of the page? A small one that no user has rights to remove? Then it's always there.
Look at my website, Website with Search Field in top left hand corner
I've got a search portlet in the top left hand corner that allows you to search google. It's always there, but it's fairly innocuous, and it doesn't disturb the user's experience. Why not do something like that?
Get this functionality out of the theme. It sounds like the theme is the wrong place. Themes should provide a common look and feel, but not really provide any real functionality other than that. Certainly communicating with a portlet is a no-no.
I know this is the better solution, but the client at the moment don�t want to change what they have. If I create the new portlet how can I pass the value to other portlet that is in other war? I can see you are a good professional developper. thanks.
Data stored in the PortletSession scope can be shared with portlets inside the same war, but not outside.
When it comes to sharing data, you've got to 'roll your own' and create your own solution.
One way is to use a common, temporary, database table. Use the portletID and clientID to create a unique entry for the user to uniquely identify a client's data. Save client specific information to this table when it comes in, and then read this table when you need it. Any portlet can connect to a JDBC database.
It's a bit more work, because you're not using the portlet API framework, but you can do it.
Cameron is going to think I'm stalking him, but wouldn't cooperative portlets be acceptable here, too?
If an action is taken on his "drop down" portlet, it can communicate information to the target portlet. I suppose if the communication needs to be "inter-page", then the availability of that functionality will depend on the Portal vendor.
I like cooperative portlets when they're the right approach.
Indeed, technologies like C2A from IBM allow portlets to talk to each other. It might tie you into a vendor, it might not be available in the future, and even if it is, it might be very difficult to find people who can maintain applications that use Click to Action - it's definitely a unique skill.
But I've worked on a few portal projects where the girls were Whiz-Bang, and were more than capable of implementing, using and maintaining C2A. It worked pretty good.