Saturday, October 15, 2005

Nobody is perfect and it is all too easy to criticise. There is something about the JSR168 portlet architecture that strikes me as a giant leap backwards. Maybe it is concept of modes (View, Edit, Help) that reminds me of my early days as a Perl programmer where a single script would deliver all the application pages. At least at first glance the portlet architecure appears to have little similarity with the much admired MVC architecture. JSR168 portlet development with all these different competing scopes existing in parallel is very confusing even for an experienced J2EE developer.

Best practices for portlet development have yet to be properly established. With the current absence of something like a portlet aware JSTL it makes current J2EE best practices difficult to translate into the portlet development arena.

This current void in the portlet technology stack is an opportunity for unscrupulous purveyors of MVC solutions and such to tout their wares as the missing pieces. I am a great admirer of Craig McClanahan's work but I have yet to see why JSF is better than Struts. This probably makes me a non-believer but if I was to choose a new framework technology to learn more about it is much more likely I would choose Spring rather than JSF. The likes of Sun's JSF are likely to benefit as Sun are shoehorning it into portlet creation wizards such as in their Java Studio Creator 2. I don't want to cast aspersions but I would also expect Oracle to take advantage of the confusion surrounding portlets by integrating JSF and their JSF extension ADF, into their portlet factory software.

Don't get me wrong, I'm sure that Sun, Oracle, IBM, Novell and all the other technologies that creep into my portlet applications by stealth will stand or fall on their own merits. However, call me old fashioned but I'd like to do the choosing of which technology I integrate into my portlets and this is why projects like Apache's Portals Bridge will be so important to make the connection between existing J2EE best practice and future portlet best practice.

I have just created an extended version of Pluto's<portlet:defineObjects/> which will make additional portlet related implicit objects available. So you can access portlet scoped attributes using pure JSTL rather than via scriptlets.

This new tag extension is an interim measure as the best way to handle the new portlet scopes would be with a portlet aware version of JSTL. From what I understand a portlet aware version of JSTL is now being developed.

Thursday, October 06, 2005

Some time back I produced a Google Maps page that would render the locations from a live GeoURL RDF feed. I also did some further experiments using XSLT with Google Maps, Google Earth, KML and GPX data formats.

Things elsewhere have moved on somewhat, William A. Slabbekoorn (aka Cybarber) has produced a set of XSLT to transform between the various GPX versions and Google Earth’s KML. He distributes these XSLTs with an IE specific format conversion hypertext application. After a quick scan, most of these XSL appear to be perfectly usable with other XSL engines (I tried some GPX conversion XSL with Javas Xalan and they worked well). There is now also a commercial application called Robogeo that can convert GPX and other formats into Google Maps html. I suspect there are probably other offerings about of which I am not aware.