Nope, I can't give you an example, because you can't do it.
Essentially, what you are saying is that you have a portal page, with a portlet on it. A user has intentionally added a portlet to that portal page. And what you want to do is, when a button or something is clicked, flip out the portlet a user wanted on their page, with another portlet that you are deciding you want the user to see. Nope, that's simply not allowed.
Don't mean to be glib, but portlet development really requires a mind shift. You have to totally rethink how you develop applications.
However, what you CAN do, is perhaps, when a button is clicked, display a different JSP to the user that displays different content. Here's a very simple, free online tutorial that talks about forwarding to JSPs from a portlet:
Alternatively, if you have a number of complex page transitions, you might want to use a Struts or Java Server Faces portlet. Bridges are avaialbe from apache. Of course, if you're a new to portlet development, you might not want to overly complicate things by integrating the struts portlet bridge, or JSF portlet bridge into your application, but it's always an option. Here are some tutorials on creating the struts portlet, and the JSF portlet:
I got a look on the bridges for the jetspeed portal but as I'm learning portal basics, I prefer to study pure portlets for now.
That's what I was wondering, and I have another question: if I have several pages and a 'pageflow' after I have forwarded to some pages, if the user clicks refresh in the browser, how will the portal know that the user was in page 5 of my flow of 6 pages? Will I have to control this manually in the portlet?
I agree with you that you should stay away from the Struts and JSF bridges for now. Master the JSR168 API first, and then move onto the portlet frameworks when the need arises. Framework portlets like Struts and JSF should be the exception, not the rule.
With complex, multi-page portlets, indeed, flow control and navigation through multiple pages will be a process that must be controlled by the developer. When a portlet is rendered on a page, be it a refresh or a link click, the doView method is invoked. Some type of flag must be placed in the session or something to indicate what is a legal page transition for the portlet, and what page a user should see. Once you start getting six or seven levels deep in a portlet, it can become very complicated, and frameworks to start to become more compelling.
-Cameron McKenzie [ March 22, 2007: Message edited by: Cameron W. McKenzie ]
I'm somewhat new to JSF, with a long Struts history, but from the portal perspective, it looks like the direction is very much JSF based. JSF seems to integrate much easier into a JSR168 framework than Struts does. From IBM's standpoint, JSF with JSR168 very much seems the direction. Can't say with Liferay or JBoss or any of the others though.
When developing pages in HTML and using the form items as JSF, it works fine like Struts or other frameworks (except for the backing beans which I believe make you APP a mess).
But when we have to develop the entire page using just JSF tags, without using HTML, this reduces my productivity a lot as when we develop in pure HTML the webdesigner does all the dirty work, but when I get a prototyped page already built in HTML I have to recreate it in JSF, I'm wasting the company's money. Not to mention that we get locked to the renderer of the implementation, which makes a lot harder to achieve simple layout changes your user may ask.
That's why I do not like JSF very much, even tough I had to use it in one project for a large company here in Brazil I still believe Struts and especially Struts 2 are much more productive.
Regards, Daniel [ March 26, 2007: Message edited by: Daniel Amadei ]