This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
John, John, John, where do we begin? Is this a live app, or just a proof of concept type scenario.
One thing that makes me a little nervous is asking a user to log in. One of the reasons for using the portal is the ease with which we can delegate the task of user management to the portal. You should use the portal to log the user in, taking advantage of the massive user management facilities provided through the portal. I believe the request object has a method that gives you the name the user used to log in.
Now for the idea of one portlet calling on another portlet. You're thinking in too much of a Struts/JSF/Servlet state of mind. This isn't really how portlets are supposed to work. I mean, you want the portlet the user used to magically disappear (I don't think that's possible), and then have two new portlets just add themselves to the same portal page, and display with information provided from the first portlet. I think you're going to have to redesign the portal to achieve this. It's not supposed to work that way.
I don't mean to be trite, but you really have to change your thinking when you move to the portal.
Here's what I might do, if you are totally committed to not using the portal user management facilities.
Create a portlet that logs the user on. Have three JSP pages: one is the landing page (index.jsp), the successful login page, success.jsp, and the loginfailed/request password page, loginfailed.jsp. When the portlet first displays, you display the landing page. If they log in successfully, you send the to the success page, and if login fails, you send them to the loginfailed.jsp page. That alleviates the need to have portlets displayed and removed from the page.
You have just hijacked your own thread, changing the subject halfway through.
One of the frustrating aspects of portlet development is the fact that the portal only allows a portlet to have one controller, essentially, the class you create that extends GenericPortlet. What happens when you have a bunch of different views? This one portlet turns into a front controller, and becomes bulky and awkward, not to mention difficult to maintain.
Trust me, you're not the first one to run into this problem.
For relatively simple portlets that are used for mild navigation, and largely the display of content, a class that extends GenericPortlet is great. For more complex, wizard-like portlets, or portlets with many navigational states, you have to start looking at moving towards a framework portlet.
People have worked hard to port both the Struts and the JSF framework to a portal environment. IMHO, JSF is much easier to get working as a portlet than Struts, and that's coming from a long-time struts developer. But, with these frameworks, you can create a multi-page, multi-state portlet as though you were creating a complex, web based application. Plus, these frameworks also provide error handling, custom tag libraries, error feedback, memento patterns, and all sorts of other great things.
I've actually just written a few tutorials on how to get a Struts portlet or a JSF portlet to work in a JetSpeed2, JSR-168 environment. If that's the route you think you're going to have to go down, let me know, and I can get you a copy of the tutorials.
Let me know what you think.
Joined: Feb 11, 2003
Thanks again for the reply and suggestion. I think portal framework approach would be good. Can you please provide the tutorials or the link for the same.
I really appreciate your help and thank you for all the valuable suggestions.
Let me know
Cameron Wallace McKenzie
author and cow tipper