This week's book giveaways are in the iOS and Features new in Java 8 forums. We're giving away four copies each of Barcodes with iOS: Bringing together the digital and physical worlds and Core Java for the Impatient and have the authors on-line! See this thread and this one for details.
I am new to portal development and maybe I am asking some very basic questions. But I would really appreciate if anyone could guide me through.
When does it become important to go with the wiring approach for portlet communication? From what I have been reading there are 3 other approaches as well that can be followed, which are as below. How do we know which one to go for:
1. The PortletSession APPLICATION_SCOPE is there. So can we not put things in the portlet session and let the other portlets read from there?
2. Also we can put in database from where all the portlets that need those parameters, can obtain them.
3. Using the wps-urlgeneration tag, we can pass parameters from one portlet to another.
So how do we know when we should use wiring and when the above three ways?
Thanks a lot [ January 27, 2008: Message edited by: Dorothy Taylor ]
Use portlet wiring when you want two portlets to communicate on certain events like click or timeout. portlets can share information using PortletSession's APPLICATION_SCOPE but target portlet will not get when source portlet has set something in session.so some event is required to trigger communication. for exa. you enter search string in one portlet and get results in another portlet.
Joined: Nov 26, 2007
So suppose that I have this scenario only like I enter a search criteria in one portlet and want to update the result is another portlet. Is wiring the only way this can be done or there is any other way as well like wps:urlgeneration etc.
Cant we try to add a Interceptor in between two portlets where in we are creating a HTTPServletRequest and put the Portlet parameter (the one which we are passing through the url generation). So as we can always retrieve the data from other portlet through the HTTPServlet Request.
but yeah always wiring will be the recommended way for the Portlet to Portle Communication.
POrtlet database can be accessible to you throught the different ways, but it can be updated in edit mode only throgh the Administrator privelages.
For me, portlet wiring has always been sorta an "IBM TERM" for mapping together two Portlets that use C2A, or Click-2-Action, an IBM specific implementation of portlet communication.
Red flags go off for me all over the place when people start talking about wiring. Not that it is always bad, but it sometimes indicates that people aren't using the portal properly, or aren't thinking from a portal mindset.
Why do two portlets need to message each other? If they are so heavily linked together, why aren't they part of the same portlet application? If they were, they could share the APPLICATION_SCOPE setting on the session, and your problem is solved.
Furthermore, why aren't the two portlets actually just one portlet? There's nothing wrong with a single, dashboard portlet. In fact, it's often a good idea. I've seen very good dashboard applications, that would be one good portlet, ripped apart into 10 different portlets, and then wired together in the most kloogy of fashions, creating a solution that is neither maintainable or manageable.
If there is shared data, put it in a commonly accessible database table. If two portlets need to respond to each other, package them as a single, common portlet. Don't fall back on wiring with C2A. It's not a long-term solution.
Joined: Nov 26, 2007
Starting this thread again after a long time, but i hope that's ok
So if I am going for co-operative JSR-168 portlets, is wiring still a not so good way of doing stuff. By wiring, I mean wiring using WSDL in Websphere POrtal server
Cameron Wallace McKenzie
author and cow tipper
It works, and it's cool. But it does have a learning curve, and whether there will be people around in the future to service it, work on it and understand it? That I'm not too sure of.
So, time to develop and ease of maintenance are my concerns. If those aren't big issues, well, C2A is pretty neat, and clients love it - gets them close to that Web 2.0 experience. There's value in that.