Back to Portlet Puzzles

The learning curve for OpenLayers and WCS was temporarily set aside again as I found that I needed to spend more time negotiating the curves in the portlet learning road.

I had the basics down well enough a few months ago when I had managed to develop the application with the SOAP Service Client Portlets. But I had been learning as I went along and I knew that the way I did things in the earlier portlets was different from what I later decided was the right way to do it. And there had been no real in-depth testing done on any of the portlets.

I set out to document a series of test cases that would make it possible for another person to do the testing. It was difficult enough to start something from scratch and decide what format to use and how detailed to make the instructions. Then as I came up with explanations and procedures I realized that there were things that I myself didn't understand very well on how they worked. Some test cases that I hadn't thought of before showed errors in my original logic. And there were cases where I had chosen to use shortcuts and display less than what was actually available as data from the service. I knew I had to spend some time refactoring the code.

Of course, whenever you start to make changes in your code it always turns out to take longer than what you planned. And when it comes to portlets there are many parts of development that I still don't understand. But after this week's efforts I can say that I finally have a better understanding of the portlet lifecycle and how to properly use the various classes and objects that are needed for portlets like the SOAP Service Client Portlets, which are primarily used to gather form data from the user and return data results for display.

I had used a lot of examples over the past year to further my learning. Some examples came from sources that were being used to illustrate the new features of JSR 286. I probably shouldn't have started with those before I had a really good understanding of JSR 168. That caused confusion by making things more complicated than the simple cases I was trying to solve.

Not until this week did I understand when I should be using getParameter/setParameter as opposed to getAttribute/setAttribute. It was a real revelation to realize that setting render parameters was all that I needed to do in order for the values obtained from the service calls in the processAction method to be available to the doView method. And that what was available in the doView would also be available in the view jsp--there wasn't a need to get the parameters in both places. "getPortletContext().getRequestDispatcher.include(request,response)" had never dawned on me that "include" meant everything was shared between the two.

It took a lot of trial and error and null pointer exceptions but where I ended up getting a lot of extra mileage was once I figured out how to use the setRenderParameters and getParameterMap to pass a whole series of data values. This made possible a total revamping of the Multi-Point GeoidHeight portlet. Whereas before I only displayed a comma-separated list of the answers, I can now display all the information in a nice table form, including original inputs, inputs converted to decimal degrees, the heights and any error messages that are returned. I vaguely remember one of the other portlets I did where I knew this was a feature I needed to incorporate but didn't want to take the time then to figure it out. There's a still a bit of cleanup on Multi-Point GeoidHeight and then I'll be continuing with the other SOAP Service Client Portlets to see what needs fixing/enhancing.