• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Liutauras Vilda
  • Ron McLeod
Sheriffs:
  • Jeanne Boyarsky
  • Devaka Cooray
  • Paul Clapham
Saloon Keepers:
  • Scott Selikoff
  • Tim Holloway
  • Piet Souris
  • Mikalai Zaikin
  • Frits Walraven
Bartenders:
  • Stephan van Hulst
  • Carey Brown

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

 
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
author and cow tipper
Posts: 5009
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
I wish to win the lottery. I wish for a lovely piece of pie. And I wish for a tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic