Did someone want to write a portlet that talks to Flash? 

How is it that a design philosophy that was intended to make communication, collaboration and integration seamless and easy ended up making it such a hard challenge to write applications that require communications between disparate technologies? I'll never know how Portlet development took a walk down such a painful path, but in this sweet tutorial, Matt Dalrymple takes the pain out of communicating between your portlets and your Flex based applications.

Portlet to Flex Communication: Making the Impossible Possible

'Making the unecessary possible' would be a better title. Flash is a must have feature for content free sites devised by marketing drones. The 'Wow' factor is 'Wow, it looks pretty but doesn't tell me anything'.

@Brandon, we just might have to hire you to pen the headlines.

I personally have a huge love-hate relationship with Flash. When abused it annoys the life out of me, and when I say abuse, I mean when it's used to do something flashy and dancy but doesn't provide an ounce of interactivity or value in terms of content delivery.

Having said that, there are 'good' flash applications, and even more so, there are often content and interactive components that have been written in Flash and need to be ported into a portal environment when a company goes that way. At that point, the interaction does become necessary, at least for the developer tasked with the job. And these types of tutorials are absolute gold - sadly, the portal community has a real dearth when it comes to tips and tricks like this.

Will HTML5 be the end of flash? Part of me hopes that it will be, so long as I can still play Desktop Tower Defense.

Having written a full blown health informatics application using ActionScript/Flex 4. I can tell you that, your eyesight must be damaged. My app looks pretty, and does LOTS. Especially with DICOM images, A/V streams, and seamless integration with J2EE backend.

In other words Brandon. Don't be so damn Myopic.

HTML5 is nice, but until the business world catches up to using web-browser standards that have a decent javascript engine, I think that there still will be a big reliance on plug-in technologies (silverlight or flash) to provide high performing components.

What plug-in technologies give you is out of the box components with a nice IDE to develop with. It allows you to quickly build complicated interaction models that are high performning for large volumes of data.  This is especially important if you are tied to an old version of IE that just can't run the nicer javasript libraries as well as you need them to be (i.e. extjs).  

I personally value a nice IDE. Most developers out there in the business world are building tactical solutions that require a short turn around to expose business functionality and information.

Its just you pay a price for this in terms of integration. Its take a bit more planning, but you can still make use of all the goodies that you get from being within the portal framework.

I despise Flash for the sake of Flash just like anyone else. But I am not speaking to banners or video content here. I want a Desktop experience.

I'm still trying to understand why people would use these bloated java portal server stacks with roots in technologies that go back to 2003. I don't know if open souce is necessarily any better - seems there are lots of disgruntled Liferay users as well.

I'll throw my hat in the ring as a disgruntled portal user, and I'm the guy that wrote the JSR 168 Portlet Programming book. I've been left wondering 'why' for a long time.

Having said that, I'm amazed by the latest Liferay offering. Downloaded and start it up and be amazed - social networking, instant messaging, wiki support, blog support, friends, document management and the like, all out of the box. It's amazing. At the very least, they're getting me to change my tune.

I'll give a different account based on my experience.  It's just ok if you want what they have out of the box.  As soon as you want to start writing your own portlets, you'll pull your hair out.  Things will seem fine at first, but the amount of time you spend tracking down little problems is mind-numbing.  Don't get me started if you want to override some of the built-in LR "features".  Try bringing a hook or ext plugin to life.  It's a serious PITA. What you end up with is a huge tax on your productivity.  You end up with a big mish-mash of portlets that don't work quite right when all you really want is something that works.  You'll long for the days when you could work with the sweet bliss of the Servlet API.  Then, when you want to hand off your project to someone else, good luck, because you can't find a portal developer to save your life.  Using LR has been a nightmare for me.  It's my 3rd LR project and I begged TPTB not to use it.  The only good thing I can say about LR is that it has forced me to learn Ruby on Rails so I can feel like I'm still a productive programmer.

HTML 5 + web sockets will most likely kill portlets. HTML 5 has new iframe features and websockets and/or cross domain messaging provide inter-iframe communication. I don't think there will be any need for complicated standards like portlets and WSRP once HTML 5 is fully adopted.

I'm still trying to understand why people would use these bloated java portal server stacks with roots in technologies that go back to 2003. I don't know if open souce is necessarily any better - seems there are lots of disgruntled Liferay users as well.

 

Have any recommendations? The mashup servers have been a wash too don't you think?. Let's not forget Portal/Portlet is just a concept.

The problem with Java Portlet technology was the JCP spec. It was so dumbed down that it didn't provide any value and most vendors went to proprietary solutions anyway. (Inter-portlet messaging one of the glaring examples).