I just finished up a little side project creating a custom Documentum UI with the Eclipse based FlexBuilder 3.0. I rarely code any more and this was my first opportunity to work with the technology. When learning new languages and techniques I find that I spend far less time these days with syntax than I do with the idiosyncrasies of the IDE’s.
I started this project immediately after test driving D6 Composer which is also Eclipse based. I was dreading it. My team’s experience with Composer was frustrating on many levels. After two days with FlexBuilder though I have to confess, I loved it. Flex Builder 3 was great! Despite radical differences in scope and purpose, I was surprised at how different my impressions were of the tools given that they are fundamentally the same IDE.
Applets and Oranges
To be fair, the scope of Composer is very different from Flex. It seems to me that the biggest challenge that Composer takes on is engineering a way of persisting Documentum configuration. Trying to normalize a common offline schema from 16 years of different design techniques embedded deep within in the content server implementation has got to be a pain. That being said, the Composer implementation doesn’t really clean that up. Pointless nomenclature changes, oceans of xml, oddball file extensions and other choices make it confusing for oldtimers set in their ways like me. BOF creation is awkward at best – no less so than in the old world. Our initial experience forced us to abandon Composer except when dealing with aspects. (because we didn’t have a choice)
Like Sands though the Hour Glass
Composer 1.0 took a REALLY long time to make its debut. If this pace doesn’t change then I think they have a problem. It may be that DocApp builder still works (mostly) and there is not a sense of urgency to replace it. Flex has been around since 2004 with 3 beta cycles before each major release and while it is similar to the major release and 2 SP pattern for EMC, the differences in capabilities are more dramatic. It strikes me that the incremental improvements trickling out of EMC in service packs come at far too slow a pace to keep up with frenzied 2.0 developers.
I am filled with questions. How will Magellan and Composer work together? Will they work together at all? Will Magellan UI customizations be constructed in Composer or are we expected to do that elsewhere. Can you customize Magellan at all? Which Darren was better on Bewitched? All these burning questions I could have asked at EMC World but didn’t get the chance. Perhaps someone will chime in with comments. Seeing Magellan work against stock use cases is great, but the IDE approach is as critical to its success.
Good Coders Borrow – Great Coders Steal
Some lines of code you should never type again. I personally haven’t written a completely original line of code since December, 1996. I think it was on a Tuesday. For example, I have yet to meet anyone who has started with an empty text file and actually written a makefile from scratch.
One of the best parts of the Flex experience was working with the library of samples. Producing functioning and well documented samples and templates for new techniques is the best thing EMC could do to drive adoption. The quicker I can be productive, the more I will like, use and recommend a tool.
While depending on the developer community to supply samples is an understandable approach, EMC should invest more (i.e. pay people) to develop a better library of examples. To say that EMC has been inconsistent in their approach here is a understatement. When BOF 1.0 was released there was real effort to standardize the documentation and communicate best practices but the consistency was short-lived.
I agree the best examples come from the community but when new technologies are released they simply don’t have the information. Perhaps as an example for aspects they’d release the implementation details of an internal use such as components of the collaboration edition. The EMC Developer Network is greatly improved but the framework is just the first step. You need content and your not going to get it all for free when it cost so much already to play with Documentum in the first place.
You Get What You Pay For – And What You Don’t
I am always more forgiving where documentation is concerned for open source. You get what you pay for right? Unlike familiar web 2.0 development platforms, Documentum requires a huge investment (time and $) to gain access. Flex isn’t free – but I could easily become productive with the tool and I only hit the company credit card for $250.00 US. An equivalent level of productivity with EMC requires a much greater commitment in time and a visit from a Brinks truck.
Even considering the head start, the Flex site had well thought out examples (delivered in a Flex browser app) and great “Help” documentation, not just the javadocs. The bar has been raised with the Magellan UI but success will require more than killing webtop with some snazzy AJAX. The IDE now has an even more challenging target to shoot for. I can only hope the Composer team is getting the investment they need and the push to live up to the expectations the Essentials Client and the Flex based Web Publishing tool have set for us all.