File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

How to pass Global parameter across portlets which are using JSR 168 API

 
GaneshKumar Kumar
Greenhorn
Posts: 24
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I am using WPS 5.1.0.1. We have developed, deployed few custom portlets (JSR 168) and added those to Portal page. There is one portlet called locale portlet. In locale portlet one dropdown list box is present. It contains locales like en_us,de etc., When the user changes the locale in dropdown, this parameter(or value) should be stored somewhere else globally and accessed by all the portlets in the page. Not in User Registry. I mean to say it will not affect the user's locale. Once receiving the locale the portlets will be displayed in the new locale.

I tried with PortletSession with application scope. As the portlets are in different .war files it failed. Is there any good way to do this. Please let me know if you have some idea?

Thanks.
Ganesh
 
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper
Posts: 4968
1
Hibernate Spring Tomcat Server
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Indeed, the application scope won't work for portlets in different WAR files.

The portal does alot of work to figure out the user's locale. It first looks at what the client supplied when they signed up, then it looks at the default for the users' browser, then it looks at the default for the portlet, then it looks at default for the portal as a whole. I'm questioning why you're adding a new layer to this already fairly solid functionality?

My suggestion would be to use a portlet service. Put the value for the user in a temporary database, using a portlet service, and map the username or unique userid to the i18n preference. Then have every portlet look at that web service.

Of course, this now means EVERY portlet you deploy needs to look at this portlet service, which is alot of redundant code. If I was architecting this solution, my initial take would be to veto this functionality. I'd need a pretty darned good business case to justify this type of functionality.

Good luck!

-Cameron McKenzie
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic