Similar to our Open Source efforts, most of our ideas for posts come from clients. For this post, we will address a question from a client evaluating Adobe LiveCycle ES2 and TSG’s Active Wizard as part of a forms effort.
“In a nutshell, what are the differences between Adobe LiveCycle and Active Wizard?”
First released with Documentum 6, Documentum Composer is a “unified development platform for assembling, configuring, and deploying EMC Documentum applications.” Currently on version 6.5 SP3, Composer is meant to be a Documentum Application Builder replacement. Although Documentum is trying to move away from Application Builder and into Composer, Application Builder is still available for use with Content Server version 6.5 applications through the use of Application Builder 5.3 SP6.5.
Since the very first Momentum (1996 in a very windy Miami), the Documentum user community has pushed for a more reliable means to convert mostly Microsoft office documents into PDF. Back then, during a wrap-up luncheon, the feedback on AutoRender ( a previous incarnation of DTS) was anything but positive. Similar to some complaints today, some of the main complaints included:
Having to monitor/reboot the AutoRender Server throughout the day
Unreliable PDF Transformation included:
Unsupported Document Types
At the time, Documentum threw some engineering effort into AutoRender to address some of the shortcomings. One of the changes was to have AutoRender reboot itself (not really a fix but it did address some of the shortcomings). Like other products from Documentum, TSG is occasionally asked for alternatives. This post will address some of the tools we use in non-Documentum environments that could easily be adapted to the PDF rendition needs for Documentum.
For a couple of our non-Documentum customers, we have leveraged the Adobe LiveCycle component PDF Generator. We have been very impressed with their reliability and functionality. Considering Adobe created the best known implementation of Portable Document Format, it makes sense to rely on Adobe technology to convert your native content.
TSG is currently in the process of creating a version of the Active Wizard that will work with our own OpenContent web services. Using OpenContent will allow Active Wizard to work with any Content Management System that OpenContent supports. This means that Active Wizard implementations will be supported on a number of repository types (ex: Documentum, Alfresco, file system). The Active Wizard will require only a simple configuration change to work with each CMS. This will also benefit users who are currently using the Active Wizard with Documentum, as it will mean that only OpenContent code will need to be updated and tested when a Documentum upgrade is implemented.
Also, a filesystem implementation of OpenContent is currently in development that will allow the Active Wizard and Active Wizard Lite to be run on open source platforms such as Apache Tomcat, Apache Derby and a simple file system structure to store XML.
Visit www.activewizard.com for more information on the Active Wizard and OpenContent, and check back here for more updates on the status of Active Wizard with OpenContent.
At the end of the day, Flex is Flash; an HTML or JSP page will have a swf file embedded in it and the Flash Player plug-in will be used to render it. Until now, most of our Flex and Flash projects have consisted of either small components within a page, or the entire page itself. In both cases the default “wmode” parameter value has always been used: “window.” Integrating the WYSIWYG control within our Flex component required using a different wmode value: opaque.
In order to integrate the WYSIWYG control into our Flex component we had to use iframes and this is what necessitated the use of the opaque wmode value. A quick Google search for “Flex iframes” turns up quite an interesting selection. One of the top hits is a project on Google Code called flex-iframe. We actually wound up using this component as it’s quite robust and works well. However, the first hit is an article titled “Don’t Use IFrames for HTML in Flex” and lists reasons why using iframes and Flex/Flash is a bad idea. One of the reasons is specifically because it requires the use of the opaque wmode value and lists the following three reasons:
Speed: There is no big surprise here, but when you force Flash to composite the HTML layers above and below, you are adding additional processor load.
Accessibility: wmode makes your movie invisible to screen readers
So what did we end up doing? Several things:
To address the performance issue we wound up not embedding FCK in our form multiple times. Instead we embedded a simple html page that we updated when the user changed content. The WYSIWYG only appears when the user clicks in the html area, via a modal popup.
The scrolling issue fix was easy to implement, however, thinking of it took a bit of time. We initially tried some of the suggested fixes posted on the JIRA page, but they didn’t seem to work us. Since the issue only affected the UI while the user was scrolling the page, we decided to simply disable “live scrolling.” That is, the user can move the scrollbar normally but the rest of the UI won’t update until the user lets go of the scrollbar.
Another advantage of GWT is that it allows debugging in a hosted mode browser, so most changes in the client side code can be viewed by simply refreshing the browser. Several plug-ins are available which allow GWT development in different development environments including Eclipse.
Here is a screenshot of our GWT Annotation tool interface. Be sure to check back often as we will be releasing our annotation demo shortly.
TSG recently had the privilege of test driving and customizing Documentum’s new collaboration solution, CenterStage Pro. CenterStage Pro is a next-generation collaboration tool and features a sleek new interface that does away with Documentum’s traditional WDK front ends.
We updated CenterStage with two very similar actions. The first action that we added launched the Active Wizard in the same window, automatically logging the user in. The user then had access to the entire Active Wizard, and when they completed their work, the “Return” link in the Active Wizard returned them to CenterStage, automatically logging them in and returning them to their last location. The second action that we added implemented all of the first action, with the addition of the ability to route a specific document using an Active Wizard form.
The overall similarities with WDK in terms of the multiple files should be an advantage to anyone familiar with WDK; however while WDK splits up the different files (ie – NLS properties, action xml, etc) into individual files for each action, CenterStage tends to group all of the string definitions into one file, all of the action definitions into one file, etc. This centralizes the work quite a bit, as you are not creating a suite of new files for each additional action.
Since CenterStage is still version 1.0, it has a limited amount of customization capabilities. Documentum has stated that an official customization SDK should be available with version 1.5.
Be sure to check out a video of our customizations in TSG’s LearningZone.