With no clear direction from management it's difficult to say if this effort to build portlets will ever go anywhere. The 7 "geoprocessing" portlets that I built months ago have languished for quite some time on the development server. Although we exposed them as WSRP portlets and demonstrated that they could then be brought into the client's SharePoint portal as WSRP Consumer Web parts, that didn't excite anyone enough to give us any indication that they are being used.
A couple of incidents over the past months provided additional proof that very few people are aware of the existence of the portlets. In one case, we discovered that the development server had been offline for almost 24 hours. We discovered that ourselves, not because any users contacted us. In another case, a configuration change to proxy settings on the server blocked the communication path between the server and the SharePoint portal. This meant that if anyone had them on a web page on the SharePoint portal, there would be an error message in the web part where the portlet should have been displayed. Again, it was only by accident that we discovered it, not because any users raised the issue.
I continue to learn new things, however, and that is an important personal goal. The last entry I had made here was after my excitement at discovering the usability of the Liferay portal. I haven't been able to work full time at becoming a more skilled Liferay user, but I have done a few things with it. Last week I decided to use a page on the Liferay instance on our development server as a "portlet portfolio."
If this work on portlets does not end up providing anything useful to the client, I will, at some point, probably find myself doing a different kind of development work. It would be nice to have something to show for what I did learn while working with portlets. Hence, the 7 "geoprocessing" portlets that are wrapped together as a single portlet application are now displayed, along with a short explanation, on our development server.
Anyone who examined the code for these portlets, myself included, would find many ways to improve them. But since they have been available for quite some time in the current form with no reaction from anyone, I don't see much point now in taking the time to improve them. I left the code alone and considered it a "baseline" and uploaded them as is. Until management tells me otherwise I will continue to build portlets and display them in this portfolio, but they will not be part of this same portlet application.
Saturday, January 23, 2010
Tuesday, November 17, 2009
Revisiting the Liferay Portal
Last June I was contacted by an acquisitions editor with Manning Publications and asked if I would be interested in reviewing an outline for a book proposal on portlets. Books on portlets are few and far between and I was more than happy to take a look at the proposal. Not only did I get a complimentary ebook of my choice from Manning, but I was asked again last week to do a review, this time of the initial chapters of the book.
Feeling as I do, that the portlet technology is far from reaching the level of acceptance that was hoped for, I remain skeptical that this book will be a best seller. I am grateful to the author, though, for all the work he has obviously had to do to create these first four chapters. If the book makes it to press, it will already be outdated, but I would not hesitate to pay the $50+ price that will probably be charged. I got lost on the 3rd and 4th chapters because I've not been exposed to the Spring Portlet MVC framework. I'm not sure I will ever be using Spring and didn't want to spend the time downloading yet another new tool. But I got enough good stuff out of the first 2 chapters that the book would be well worth the price.
Anything that I can find in printed form about portlets is valuable in building up my knowledge and understanding. I found the first 2 chapters to be a good summary and review of the portlet architecture. In several areas there were sections that lit up the proverbial light bulb. For example, I could certainly relate my experiences to the section on "Choosing a Portal Server." It helped me realize part of the reason why learning to develop portlets has been such a struggle. There is no one who understands why a portal is needed in our environment. Without knowing the requirements it's been hard to have a direction and purpose for struggling down this path.
What I will be most grateful to the author (Ashish Sarin) for is the instructions and explanations he provided for downloading and installing the Liferay portal and the Eclipse IDE. Because I had just finished a two-week effort to install WebLogic Server 10.3, WebLogic Portal 10.3 and WebLogic Workshop on a Linux virtual machine I had the basis for contrasting something lightweight and simple with something that was an installation and configuration nightmare. If I had been able to have Sarin's manuscript in hand a year and a half ago when I started this whole portlet thing, I might have been a much happier developer.
Why did I want to fight with WebLogic in the first place? Well, we have needed some way to verify that when we develop portlets they are JSR 168 compliant. We use the NetBeans IDE with portlet plug-ins to develop the portlets and Sun's Open Portal Portlet Container to deploy them. Early on I had tried using WebSynergy (which became Web Space Server) but gave up in frustration. I know that it is built on top of Liferay and some would say that it is the same thing as Liferay, now that the 2 Open Source projects were combined. But I did not find it at all easy to understand, maybe because I didn't realize at the time how closely tied it was to Liferay. I was always trying to find documentation by going to the Sun forums and wikis. I hadn't gotten involved with the Liferay community.
Sarin's book, complete with illustrations and step-by-step instructions, gave me the courage to give Liferay and Eclipse another try. I was blown away at how easy it was to get up and running and to deploy the first JSR-168 test portlet. After the hours spent with WebLogic I still did not know how to do the simple task of deploying a JSR-168 portlet. That was the reason in the first place that I went to the trouble of installing it. Although I finally did get a JSR-168 portlet installed on WebLogic, I dread ever having to do it again. To give you an idea of the nightmare look at the forum thread.
We should be able to use Liferay as our JSR-168 portlet testbed. It's quite simple to upload and install a portlet application. And there's so much more out-of-the-box functionality that can be added. Asking management to take a look at the portlets we deployed on Portlet Container was a bit embarrassing because of the barebones interface. I hope to have time to build up some nice looking pages and capabilities on Liferay.
Feeling as I do, that the portlet technology is far from reaching the level of acceptance that was hoped for, I remain skeptical that this book will be a best seller. I am grateful to the author, though, for all the work he has obviously had to do to create these first four chapters. If the book makes it to press, it will already be outdated, but I would not hesitate to pay the $50+ price that will probably be charged. I got lost on the 3rd and 4th chapters because I've not been exposed to the Spring Portlet MVC framework. I'm not sure I will ever be using Spring and didn't want to spend the time downloading yet another new tool. But I got enough good stuff out of the first 2 chapters that the book would be well worth the price.
Anything that I can find in printed form about portlets is valuable in building up my knowledge and understanding. I found the first 2 chapters to be a good summary and review of the portlet architecture. In several areas there were sections that lit up the proverbial light bulb. For example, I could certainly relate my experiences to the section on "Choosing a Portal Server." It helped me realize part of the reason why learning to develop portlets has been such a struggle. There is no one who understands why a portal is needed in our environment. Without knowing the requirements it's been hard to have a direction and purpose for struggling down this path.
What I will be most grateful to the author (Ashish Sarin) for is the instructions and explanations he provided for downloading and installing the Liferay portal and the Eclipse IDE. Because I had just finished a two-week effort to install WebLogic Server 10.3, WebLogic Portal 10.3 and WebLogic Workshop on a Linux virtual machine I had the basis for contrasting something lightweight and simple with something that was an installation and configuration nightmare. If I had been able to have Sarin's manuscript in hand a year and a half ago when I started this whole portlet thing, I might have been a much happier developer.
Why did I want to fight with WebLogic in the first place? Well, we have needed some way to verify that when we develop portlets they are JSR 168 compliant. We use the NetBeans IDE with portlet plug-ins to develop the portlets and Sun's Open Portal Portlet Container to deploy them. Early on I had tried using WebSynergy (which became Web Space Server) but gave up in frustration. I know that it is built on top of Liferay and some would say that it is the same thing as Liferay, now that the 2 Open Source projects were combined. But I did not find it at all easy to understand, maybe because I didn't realize at the time how closely tied it was to Liferay. I was always trying to find documentation by going to the Sun forums and wikis. I hadn't gotten involved with the Liferay community.
Sarin's book, complete with illustrations and step-by-step instructions, gave me the courage to give Liferay and Eclipse another try. I was blown away at how easy it was to get up and running and to deploy the first JSR-168 test portlet. After the hours spent with WebLogic I still did not know how to do the simple task of deploying a JSR-168 portlet. That was the reason in the first place that I went to the trouble of installing it. Although I finally did get a JSR-168 portlet installed on WebLogic, I dread ever having to do it again. To give you an idea of the nightmare look at the forum thread.
We should be able to use Liferay as our JSR-168 portlet testbed. It's quite simple to upload and install a portlet application. And there's so much more out-of-the-box functionality that can be added. Asking management to take a look at the portlets we deployed on Portlet Container was a bit embarrassing because of the barebones interface. I hope to have time to build up some nice looking pages and capabilities on Liferay.
Friday, October 2, 2009
Mystery solved
I guess I had expected something more in the way of documentation for OpenLayers that would explain the behavior of the different cases I had created for trying to display my KML file on an OpenLayers map. But thanks to Scott Davis, who does a marvelous job of teaching "GIS for Web Developers", I now have an OpenLayers map that displays the KML in Firefox and in IE. Both browsers are consistent in handling the display for both the OpenLayers.Layer.Vector class and the OpenLayers.Layer.GML class. I can't say that I understand everything that's happening behind the scenes or which of the two classes is the preferred one to use. But I do understand a whole lot more about JavaScript and OpenLayers and troubleshooting than I did before.
"Due to security restrictions in Javascript, it is not possible to retrieve information from remote domains via an XMLHttpRequest. Classes like Layer.WFS and Layer.GeoRSS use XMLHTTPRequest to get their data." Those two statements from the OpenLayers FAQ page were the key to solving the problem. I think I had suspected that before taking Scott's class, but I suffer from a need to know exactly why things work the way they do, even in the most obscure details that most people don't care about. I wanted to see something in black and white that said if you are using the Layer.Vector and Layer.GML you need to have a proxy. The OpenLayers examples for KML don't show the proxy host variable being set like they do for the Layer.WFS examples. I guess I was being a bit laxy, too, and not wanting to create a servlet to make the call if I didn't have to.
But without getting into the gory details, Scott assured me that if I just accepted the rule that the HTML with the JavaScript must be in the same domain as the server from which the data is being retrieved my problems would go away. I bit the bullet and created a servlet to intercept the OpenLayers call, grab the data from the remote domain and push it back to OpenLayers. Now I know to always use a proxy. And I have a better proxy servlet than the first attempt at a servlet I made months ago when I was using the Layer.WFS class.
For anyone who is doing web development that involves GIS and has struggled with the learning curve, I highly recommend purchasing the book "GIS for Web Developers" by Scott Davis. And to really get a good foundation check out his class.
"Due to security restrictions in Javascript, it is not possible to retrieve information from remote domains via an XMLHttpRequest. Classes like Layer.WFS and Layer.GeoRSS use XMLHTTPRequest to get their data." Those two statements from the OpenLayers FAQ page were the key to solving the problem. I think I had suspected that before taking Scott's class, but I suffer from a need to know exactly why things work the way they do, even in the most obscure details that most people don't care about. I wanted to see something in black and white that said if you are using the Layer.Vector and Layer.GML you need to have a proxy. The OpenLayers examples for KML don't show the proxy host variable being set like they do for the Layer.WFS examples. I guess I was being a bit laxy, too, and not wanting to create a servlet to make the call if I didn't have to.
But without getting into the gory details, Scott assured me that if I just accepted the rule that the HTML with the JavaScript must be in the same domain as the server from which the data is being retrieved my problems would go away. I bit the bullet and created a servlet to intercept the OpenLayers call, grab the data from the remote domain and push it back to OpenLayers. Now I know to always use a proxy. And I have a better proxy servlet than the first attempt at a servlet I made months ago when I was using the Layer.WFS class.
For anyone who is doing web development that involves GIS and has struggled with the learning curve, I highly recommend purchasing the book "GIS for Web Developers" by Scott Davis. And to really get a good foundation check out his class.
Thursday, September 24, 2009
KML file on OpenLayers Map
This effort started with the creation of a simple KML file using http://www.geodistance.com. By using the map on the site, a bike route near my home could be traced out and saved as a KML file to my local hard drive. The goal was to create a local HTML file that had an OpenLayers base map layer and the KML file as a second layer on the map.
There were 2 different live examples on the Open Layers site of how to display a KML layer. One of them used an OpenLayers.Layer.Vector object and the other used an OpenLayers.Layer.GML object. Both examples referenced the KML file to a kml subdirectory that exists on whatever web application OpenLayers uses to run the live examples.
Rather than download the library to my local server I chose to include the library with the single script element. I did not have a kml subdirectory under the directory with the HTML file that I was creating—I simply copied the KML file into the same directory as the HTML.
By the time that I got finished with this experiment I ended up with 4 different HTML files. Internet Explorer (Version 7) and Firefox (Version 3.5.3) were the 2 browsers I was using and they both acted differently, depending on whether the KML file was on my local drive or whether I put it on a server reachable over the Internet. Using the 2 different methods of creating the layer caused different behavior, as well.
If the KML file was on my local drive then IE could not find the file at all. It was not obvious that IE was having trouble with the fact that the file was on the local drive. The error message was “Access is denied: Line 1078”, which in the debugger pointed to a place in the OpenLayers.js that did not provide much of a clue as to what kind of access was being denied. It was only by finally uploading the KML to a remote server and providing the full URL, rather than just the local file name, that I got it to work in IE.
Using the local KML file and the two IE failure cases, one being the OpenLayers.Layer.Vector and the other the OpenLayers.Layer.GML, produced 2 different behaviors. When the Vector example failed it would fail to display the map, as well as failing to display the KML. The GML example would at least display the map and just fail to display the KML.
Firefox did not display any error messages when I used the local KML file. But it did not display the KML layer when I used OpenLayers.Layer.Vector. Using Firebug did not provide any information as to why it couldn’t display the Vector layer. But it did display the GML layer. And, unfortunately, if I used the HTML files with the full URL to the KML on the remote server Firefox could not display the KML for either the Vector or the GML. Firebug showed no errors for the Vector method; for the GML method it showed a “no element found” error in the Console Response tab.
All of this leaves me with 4 different HTML files where the only thing different amongst the four is the single “var bikeroute = “ statement where I create a KML layer for the map. None of the 4 files provides a satisfactory solution to what I’m trying to do. I have a local KML file that I want to display on an OpenLayers map in a consistent manner whether I use IE 7 or Firefox 3.5.3. Everything I’ve discussed can be reproduced with no special software and only the 4 HTML files and the KML file. If anyone could decipher for me what is going on with OpenLayers when I try to display a KML file I would greatly appreciate it.
There were 2 different live examples on the Open Layers site of how to display a KML layer. One of them used an OpenLayers.Layer.Vector object and the other used an OpenLayers.Layer.GML object. Both examples referenced the KML file to a kml subdirectory that exists on whatever web application OpenLayers uses to run the live examples.
Rather than download the library to my local server I chose to include the library with the single script element. I did not have a kml subdirectory under the directory with the HTML file that I was creating—I simply copied the KML file into the same directory as the HTML.
By the time that I got finished with this experiment I ended up with 4 different HTML files. Internet Explorer (Version 7) and Firefox (Version 3.5.3) were the 2 browsers I was using and they both acted differently, depending on whether the KML file was on my local drive or whether I put it on a server reachable over the Internet. Using the 2 different methods of creating the layer caused different behavior, as well.
If the KML file was on my local drive then IE could not find the file at all. It was not obvious that IE was having trouble with the fact that the file was on the local drive. The error message was “Access is denied: Line 1078”, which in the debugger pointed to a place in the OpenLayers.js that did not provide much of a clue as to what kind of access was being denied. It was only by finally uploading the KML to a remote server and providing the full URL, rather than just the local file name, that I got it to work in IE.
Using the local KML file and the two IE failure cases, one being the OpenLayers.Layer.Vector and the other the OpenLayers.Layer.GML, produced 2 different behaviors. When the Vector example failed it would fail to display the map, as well as failing to display the KML. The GML example would at least display the map and just fail to display the KML.
Firefox did not display any error messages when I used the local KML file. But it did not display the KML layer when I used OpenLayers.Layer.Vector. Using Firebug did not provide any information as to why it couldn’t display the Vector layer. But it did display the GML layer. And, unfortunately, if I used the HTML files with the full URL to the KML on the remote server Firefox could not display the KML for either the Vector or the GML. Firebug showed no errors for the Vector method; for the GML method it showed a “no element found” error in the Console Response tab.
All of this leaves me with 4 different HTML files where the only thing different amongst the four is the single “var bikeroute = “ statement where I create a KML layer for the map. None of the 4 files provides a satisfactory solution to what I’m trying to do. I have a local KML file that I want to display on an OpenLayers map in a consistent manner whether I use IE 7 or Firefox 3.5.3. Everything I’ve discussed can be reproduced with no special software and only the 4 HTML files and the KML file. If anyone could decipher for me what is going on with OpenLayers when I try to display a KML file I would greatly appreciate it.
Monday, August 31, 2009
More Open Layers Frustrations
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.
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.
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.
Tuesday, July 7, 2009
File Upload Component in NetBeans 6.5
My next portlet has a requirement to provide the ability for a user to browse their local filesystem and select a file to be uploaded to the server. Support for this in HTML forms has been around for awhile by using a form attribute enctype="multipart/form-data" and attribute type="file" in the form input element. The HTML form is the easy part to understand. The hard part is knowing what to do on the server-side when the form is submitted.
Since I have been using NetBeans 6.5, I decided to try to find an example of how to do this in a NetBeans project. Searches led me to a NetBeans tutorial "Uploading Files in NetBeans Visual Web JSF Application." I'm not familiar with Visual Web JSF but a step-by-step tutorial looked like something I could follow. And if I had the code in a NetBeans Web Application project then it should be easy enough to take the pieces I needed and put them in a portlet project.
I made sure that I had all the software and resources that were listed as requirements. I looked through the NetBeans plugins and installed those related to JSF and Visual Web JSF. Even though the tutorial didn't say anything about plugins it seemed logical that those would be needed. A couple of missing references went away when I installed the plugins after an initial attempt to make a project with the Visual Web JavaServer Faces framework. Unfortunately, I never got any further.
I fiddled around for a day trying different plugins and looking on the web and posting to the NetBeans forums. But I'm stuck with a Reference problem--"jsf12-support library could not be found". I also noticed that all of the default source files that get created are unable to import anything from com.sun.rave.web.ui.appbase. This is in spite of the fact that the IDE shows that the libraries are there in the appbase.jar.
Enough of messing around with the NetBeans framework. Back to the web to look around for other examples. Surely there has to be a way to do this that doesn't require JSF. After all, it looks to me like the JSF is only a convenience for creating buttons and form fields on the HTML part of the application. It doesn't seem tied to the back-end server processing.
Finally, at http://www.scribd.com/doc/220346/How-to-upload-files-using-JavaServer-Pages I found something that looked simple enough. I needed a few tweaks to get it to work within the portlet environment but, lo and behold, I can now upload files. And with only about 30 lines of code in the processAction method of the portlet class. Thanks so much to whomever posted the Scribd document.
Since I have been using NetBeans 6.5, I decided to try to find an example of how to do this in a NetBeans project. Searches led me to a NetBeans tutorial "Uploading Files in NetBeans Visual Web JSF Application." I'm not familiar with Visual Web JSF but a step-by-step tutorial looked like something I could follow. And if I had the code in a NetBeans Web Application project then it should be easy enough to take the pieces I needed and put them in a portlet project.
I made sure that I had all the software and resources that were listed as requirements. I looked through the NetBeans plugins and installed those related to JSF and Visual Web JSF. Even though the tutorial didn't say anything about plugins it seemed logical that those would be needed. A couple of missing references went away when I installed the plugins after an initial attempt to make a project with the Visual Web JavaServer Faces framework. Unfortunately, I never got any further.
I fiddled around for a day trying different plugins and looking on the web and posting to the NetBeans forums. But I'm stuck with a Reference problem--"jsf12-support library could not be found". I also noticed that all of the default source files that get created are unable to import anything from com.sun.rave.web.ui.appbase. This is in spite of the fact that the IDE shows that the libraries are there in the appbase.jar.
Enough of messing around with the NetBeans framework. Back to the web to look around for other examples. Surely there has to be a way to do this that doesn't require JSF. After all, it looks to me like the JSF is only a convenience for creating buttons and form fields on the HTML part of the application. It doesn't seem tied to the back-end server processing.
Finally, at http://www.scribd.com/doc/220346/How-to-upload-files-using-JavaServer-Pages I found something that looked simple enough. I needed a few tweaks to get it to work within the portlet environment but, lo and behold, I can now upload files. And with only about 30 lines of code in the processAction method of the portlet class. Thanks so much to whomever posted the Scribd document.
Subscribe to:
Posts (Atom)