Since the "SOAPServiceClients" portlets have gained some acceptance I decided that I would work on enhancing the portlet that calculates distance and bearing. To make it easier for the user to enter a pair of coordinates I had an HTML div in the portlet that displayed an OpenLayers map. One of the coordinate pairs was selected with a mouse click on the map and the other was selected with a double-click. That populated the coordinate text boxes and then by selecting the OK button the web service would be called that returned the distance and bearing between the 2 points. What was missing was the ability to see the points and line between them on the map display.
Another developer who had done this successfully in a web application told me that it was simple to implement this functionality and referred me to the API explanation at http://dev.openlayers.org/docs/files/OpenLayers/Control/DrawFeature-js.html. I remembered that I had looked at this once before and ran into trouble before I figured out how to use it. I dug up the earlier HTML file and started to investigate.
The DrawFeature control works with an OpenLayers.Layer.Vector layer. The first step would be a constructor that created a vector layer object. Nothing difficult here, right?
var vectors = new OpenLayers.Layer.Vector("Vector Layer");
Because I was looking at an example from http://openlayers.org/dev/examples/ there were a number of other lines of code I had added to try to get the functionality in the web page that I was creating. The example would work in Firefox, but IE7 refused to display the map and the only clue was an error message "Unspecified error Line 599 character 208". I tracked this down to the constructor line by eliminating all the other DrawFeature code that I had added. So what was wrong with the constructor line? If I commented out that line the map would load in IE7, but when I uncommented the line I would get the "unspecified error" message.
After much frustration I found a different example and noticed that the vector constructor and most of the other OpenLayers initialization was being done within the head tags of the HTML, instead of within the body tags where I had it. With portlets you are not allowed to use the head tag so I had learned that all JavaScript I needed had to be done within the body tag. I temporarily moved the one statement for the Vector layer constructor out of the body and into the head. Lo and behold, IE7 quit complaining about an unspecified error and went ahead and displayed the map.
Now I had occasion to thank Javier who posted a comment to one of my earlier blogs, letting me know that I could get around the portlet restrictions of not using the head tag, by creating an init() function and then calling it from within the map div tag. Sure enough, that worked. I have no idea what it is with OpenLayers and IE7 that runs into a problem with the location on the page of the Vector Layer constructor. All I know is that it has taken up most of my time today and I still haven't even gotten to the part of creating the DrawFeature control.
Monday, August 31, 2009
Are portlets "Dead" Technology?
I was tempted a couple of weeks ago to post here and say goodbye to working with portlets. Some of the portlets I'd been working on were beginning to get attention from management and we were asked to develop test plans for portlets that would demonstrate compliance with the JSR168/286 and WSRP 1.0/2.0 specifications.
Hoping to build off what others had done in this arena I began researching what was available on the Internet. One of the first articles I came across, http://today.java.net/pub/a/today/2009/01/20/jsr-286-portlet-irrelevance.html, expressed many of the frustrations I'd encountered this past year. I did some forum postings myself and got answers like this:
https://wsrp.dev.java.net/servlets/ReadMsg?list=users&msgNo=494
The test script tool on SourceForge was once maintained by IBM (NetUnity Software) but a representative I contacted from NetUnity said "There has not been much activity for quite some time". Others told me similar things about the failure of the JSR168/286 and WSRP technologies to gain industry acceptance. That explains a lot of the difficulty this past year in finding help from other developers.
But, life goes on, and management doesn't necessarily want to hear that what you've spent all this time and money on is something that you think should be thrown out the window. Plus we had a major success with the group of portlets I had developed called "SOAPServiceClients". We deployed them on a virtual server loaded with GlassFish v2 and Portlet Container with the WSRP Open Portal plug-in. I exposed them as WSRP Producer portlets and a SharePoint portal was able to consume them.
For various political reasons that I won't go into here, the client that our team supports had been very anxious to see if this is something that could be accomplished. In theory, a Java shop can develop portlets that expose Web Services written in Java and then a Microsoft shop can display those Web Services in a presentation layer that is a WSRP Consumer web part in SharePoint. Theory and practice are often two different things and it's hard to find examples where this has actually been done. The client was very happy with the results, but I'm not sure what the real benefit is in the long run. It was a lot of work to just have a simple window on a web page where you can enter coordinates and calculate distance and bearing.
Hoping to build off what others had done in this arena I began researching what was available on the Internet. One of the first articles I came across, http://today.java.net/pub/a/today/2009/01/20/jsr-286-portlet-irrelevance.html, expressed many of the frustrations I'd encountered this past year. I did some forum postings myself and got answers like this:
https://wsrp.dev.java.net/servlets/ReadMsg?list=users&msgNo=494
The test script tool on SourceForge was once maintained by IBM (NetUnity Software) but a representative I contacted from NetUnity said "There has not been much activity for quite some time". Others told me similar things about the failure of the JSR168/286 and WSRP technologies to gain industry acceptance. That explains a lot of the difficulty this past year in finding help from other developers.
But, life goes on, and management doesn't necessarily want to hear that what you've spent all this time and money on is something that you think should be thrown out the window. Plus we had a major success with the group of portlets I had developed called "SOAPServiceClients". We deployed them on a virtual server loaded with GlassFish v2 and Portlet Container with the WSRP Open Portal plug-in. I exposed them as WSRP Producer portlets and a SharePoint portal was able to consume them.
For various political reasons that I won't go into here, the client that our team supports had been very anxious to see if this is something that could be accomplished. In theory, a Java shop can develop portlets that expose Web Services written in Java and then a Microsoft shop can display those Web Services in a presentation layer that is a WSRP Consumer web part in SharePoint. Theory and practice are often two different things and it's hard to find examples where this has actually been done. The client was very happy with the results, but I'm not sure what the real benefit is in the long run. It was a lot of work to just have a simple window on a web page where you can enter coordinates and calculate distance and bearing.
Subscribe to:
Posts (Atom)