Adobe Livecycle and ActiveWizard Comparison

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?”

This is a difficult question for a few reasons: Continue reading

Documentum Application Builder vs. Documentum Composer

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.

Continue reading

Documentum Transformation Services (DTS) – Alternative Approaches with Adobe LiveCycle and OpenOffice

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
    • Font Replacement
    • Broken links

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.

Adobe LiveCycle

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.

Continue reading

Active Wizard to use OpenContent

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 for more information on the Active Wizard and OpenContent, and check back here for more updates on the status of Active Wizard with OpenContent.

Working with Adobe Flex and iframes

As part of the upcoming Active Wizard 4.0 release, and as a result of a client’s requirement, we recently added a new input type: WYSIWYG. The WYSIWYG input type allows users to style and format text just like in a word processing application. After evaluating some of the popular HTML/JavaScript based editors we finally decided on FCKEditor (now CKEditor.) Another new feature of Active Wizard 4.0 is an Adobe Flex based Active Form component. Integrating these two new features proved to be quite the challenge.

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:

  1. 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.
  2. Accessibility: wmode makes your movie invisible to screen readers
  3. Inconsistent Performance

At various points during development, issues 1 and 3 came up and were quite problematic. Regarding the speed issue, we noticed that the more complicated content an iframe contained the slower the performance was. Surely this could be expected to some degree, however, given that we were embedding complex JavaScript based WYSIWYG controls, our iframe content sometimes became all but unusable. Inconsistent performance also left us scratching our heads: two separate views that shared quite a bit of code wound up performing differently when their content was scrolled, but only in Internet Explorer. Fortunately, Adobe’s JIRA system already had that bug logged. Unfortunately the bug was still listed as open with no plans from Adobe to be fixed anytime soon.

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.

Flex  iFrames

In the end we wound up with a rather elegant solution that’s transparent to the end-user; they don’t know that they’re using a combination of Flash, HTML and JavaScript, it just works. While we hope Adobe eventually addresses the issue with wmode we would rather they create a better rich text editor (RTE.) We only went with the HTML/JavaScript RTE because the built-in Flex RTE wasn’t robust enough for our requirements. Had it been able to support superscript and subscript, copying and pasting from MS Word and the ability to output XHTML we would have gladly used it. While there are hacks to achieve some of those requirements, copy and pasting from MS Word doesn’t appear to be possible at this time. Hopefully Adobe will either enhance the built in RTE or offer official support for integrating HTML/JavaScript (via iframes or something else.) In the meantime all we can do is come up with creative solutions that work as best as possible given these limitations.

Thin Client Annotation tool uses Google Web Toolkit

As part of our design and development for our Thin-Client annotation tool, we decided to combine the Google Web Toolkit (GWT) and Flex as the main implementation technologies. GWT is a relatively new set of open source tools that allows you to create and maintain front-end JavaScript applications in Java. This means that the front end code is written in Java that is compiled by GWT into optimized JavaScript that works across all major browsers. Eliminating handwritten JavaScript can greatly simplify front-end coding. However, if the application needs to do something that GWT cannot, JavaScript can be inserted straight into the Java program. A number of widget libraries are available from Google and third parties but if none suit a specific needs (as was the case with our sticky notes); it is quite simple to create a custom widget.

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.

GWT’s layout concept can be the main learning curve for developers unfamiliar with GWT.  Most of the page layout is based on the placement of horizontal and vertical panels. All widgets in a horizontal panel will appear on the page lined up horizontally. If the user wants one of the widgets to be below the rest, that widget will need to be placed in a vertical panel with the previously mentioned horizontal panel. Once the layout concept is grasped, it quickly becomes quite intuitive but it was frustrating at first. The only other issues we ran into came from the fact that GWT does so much internally (JavaScript compiling, RPC calls, etc), this can make debugging more difficult since it can be hard to identify what the actual root of a problem is.

Overall, GWT was a great tool for front-end JAVA development. It eliminated a lot of time that would have to be devoted to JavaScript development. There are some really helpful tutorials on the Google Code website ( ) for anyone interested in learning more about development in GWT.

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.

GWT Annotation Interface
Google Web Toolkit Annotation Interface

TSG Labs – Customizing Documentum’s CenterStage Pro

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.

To become familiar with the inner workings of CenterStage, we experimented with customizing the application to allow users to access our Active Wizard routing and approval tool. This is a common customization we see with many clients. The main difference between CenterStage and all previous Documentum web applications is it relies on JavaScript to do all of the work, including the implementation, as opposed to WDK’s use of Java on the backend. More specifically, CenterStage utilizes ExtJS. ExtJS is a cross-browser JavaScript library for building rich internet applications. The implementation of the actions that we created uses JavaScript objects, populated with Documentum properties for the current object, in order to pass the correct parameters into the Active Wizard.

Customization of CenterStage Pro Top Nav

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.

Customized File Actions Menu

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.

CenterStage surprised us with its overall ease of adding the simple actions that we set out to implement. The lack of documentation made the original development somewhat difficult, as we were forced to look through the existing code to see what kind of methods existed on the JavaScript objects that Documentum was using. However, once we were able to utilize a select group of methods to our advantage, putting together the implementation for our actions was relatively simple.

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.