OK, not really, but I figured this would grab your attention. Actually for for the current project I am working on we are using WebSphere Portlet Factory (WPF) as the main development tool. This is a first for me, mostly because my background is more traditional J2EE architect and development I have been engaged with customers and projects using the Portlet or IBM API, Struts, or more recently JSF. I have been through WPF training and on a few projects I have been on teams which were split, with some developers using WPF and others coding in Java, but even on these projects I had not really seen first hand the coding effort involved for building a non-trivial WPF portlet.
As part of my role within Software Services for Lotus, I have taken on the daunting task of trying to help customers understand when to use a particular approach or tool for portal development, so this current effort is really important in helping me to understand the power and limitations of the factory in building a large application. Usman Memon, my good friend, and crazy WPF advocate has been trying to convince me for years about the power of WPF. Many of the claims around the tool I have always taken with a grain of salt, but this time we were able to make the discussion more tangible by focusing on real world deliverables.
I had started some discussions around this topic recently with my blog entry Too Many Development Tools?, but I think I am only scratching the surface. Folks that read this blog or know me understand that these efforts are a journey. Since I flirt between infrastructure, development, architecture, or whatever depending upon who I'm working with at the current time, it may end up taking months or years to sort this all out. This is especially true when you think about customers who want to use Flex2, SpringMVC, or anything else you can imagine. Yes, I have actually talked to customers who want to use these frameworks, and in most cases they are quite valid approaches, but from a delivery side it is difficult to understand them all and make recommendations.
So, back on point, this particular project happens to include some SAP integration. Usman was leading some of the developers (including me) in how this integration could be built with WPF. The results were truly impressive, being able to connect and build out a simple call within a few hours of coding and design discussions. At one point we had to drop into creating a java class to help parse the data into a format that was easier for the factory to deal with and display. Originally I thought this was a limitation of WPF, but thinking more reasonably it is just a fact of the tool. You might actually consider it a feature the way the factory lets you extend the tooling with custom java classes and libraries. One point to consider here is that some Java skills may be necessary for anything beyond a trivial application.
So far, I do have a few additional issues not related to coding. They have to do with items like separation of projects, source control, automatic builds of the factory war, but members of our team are sorting those items out. It may be a case of me having to adjust my views on how things are supposed to be done. Imagine that? My goal is to continue to build out a few more portlets and measure the learning curve, and the value, against other technologies. We'll see how things end up... maybe I have been converted after all?
Portlet Factory has made me a convert!
JoeyBernal 1200007EAE 4 Comments 1,363 Visits