Uploaded...

Great job done by everyone, really amazed at what we've managed to achieve in such little time. For me it shows how simple the technologies we've used, DFS & GWT are to learn and build with. It's also a great reflection on the strength of our team, who attacked the problem with creativity and controlled aggression, fending off any issues and were solid under the high ball.

Well done guys, time to go and watch some rugby...

Time's Up

Our dev time is coming to a close, we've put a code freeze on as Alex compiles and packages the project for submission. I feel that we've achieved a fair bit given 5 man days - we were even able to use the product as a tool for sharing the project plan around from about half way through!

It's been a great learning experience for two new technologies. From the DFS side, I think we're all quite familiar with the new architecture and on the whole see a number a benefits. One downside we all agree on is that, on the whole the construction of DataObject structures is very 'heavy' and requires many more lines of code than the DFC equivalent. There is a lot of scope for writing a number of wrappers and convenience tools for reducing the amount of code needed for new DFS functionality. Similarly, being coarse-grained provides flexibility but again means some code is less readable and less convenient than before.

I'm sure with a bit of time to develope your own layer on to of the DFS client libraries, DFS will become a great way of developing web or thick client apps using whichever app technology you desire.

In-line Document Authoring

With the properties dialog working (to an extent), I looked at building a component for creating rich text documents within the app. The latest GWT version has a rich text editor control which fit the bill nicely. Now we have a great little tool for getting rich text content authored and into the docbase quickly - similary in some ways to web publisher's editor.

From the DFS side of things, again the coding was straightforward. Content transfer makes things a little more involved, as I had to decide which Content implementation to use to submit the rich text to the Object Service. The GWT allows us to retrieve the entered rich text on the web-app side, as a String containing the rich text in HTML format. This String can then be passed directly to the Object Service - using the BinaryContent implementation (after the String is converted to a byte[] array). I also decided to set the content transfer type to Base64, although an enhancement might be to switch to MTOM if the entered text is really large...

Still, a working rich text document creation tool - built in 2 hours!

New Documents and Folders

Having got the view document content working, I then completed the Import new document functionality and then also worked on the create new folder functionality. Both of these are now working.

Looking through our code, I can see that we have really been taking the term 'rapid' development to a new level. There isn't half as much code reuse as I would like to see and we haven't really got the time to refactor as we should.

I have noticed that the amount of code required to implement a piece of functionality using the DFS is quite a bit bigger that the equivalent amount of code using the old DFCs. I guess this was to be expected. I imagine in the future we will wrap most of the common DFS code into convience methods to make development easier.

Final thoughts... interesting.

The Properties Dialog

Isn't it nice to be able to develop (and run!) clients for two different Documentum product versions on the same workstation at once? Here I am writing code that interfaces with DFS 6 for this challenge, whilst at the same time writing enhancements and bug fixes for existing applications that use DFC 5.3. One thing that I'm excited about is the removal of all native libraries from the client's stack - making it much easier to have multiple client library versions in use on one machine (on Windows, at least!)

My first job is to develop the properties dialog for Gtop, which initially will just allow the user to view and update document attributes. So far, interacting with the DFS has been quite straightforward, making use of the Object Service to get and update properties. The only slight irritation is that the Gtop client-side code can not directly construct (or access) the DataPackage object required by the DFS service - because it does not implement the 'IsSerializable' interface that all GWT client-side classes must do. As a result, I have to convert the PropertySet DFS class to a HashMap before sending it to the client code, and vice versa when sending the changed properties back to the DFS. Perhaps some kind of adaptor, or extension of DataPackage that implements IsSerializable is in order....

Content Transfer is never easy

It seems that content transfer will never be an easy task. There is just some much going on. Still, the new DFS setPostTransferAction does seem promising. After several hours of work it looks like we have some rudimentary content transfer occurring. Currently not ideal, but with some extra time it would be.

Integrating GTOP with the DFS framework is where most of my effort is being directed. Currently I can retrieve a DataObject (with Content as per the ContentProfile) in my Google Server Side Implementation, however getting this content object across to the client is proving difficult. The GTOP client does not 'understand' the DFS classes which makes things difficult. I have decided to not use UCF, but rather use the URL as standard HTTP transfer mode. This decision was made due to time constraints.

New approach to our Content Transfer

Well after some hard thinking we have decided to change our approach to content transfer. Previously we were making us of URLs, however now we have decided to construct a Servlet which will make use of the DFS and retrieve the document content and then place this content into the HttpServletRespone object.

One thing of note was that I discovered that the Content object does not detail the mime_type for a document which is being retrieved. It does contain the format of the document but one needs to then perform a subsequent query using the QueryService to retrieve the appropriate mime_type. I may have overlooked something, but it would be a nice feature to include the mime_type in the content object so as to reduce client / server communication.