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.

we have a logo

inspired by andrews login wait prompt, we have a panther springing from the ledge of 5 man days, over the application, it's that old rule poking it's ulgy head again, developers and graphics should never be mixed...

Feeling the pressure

We've broken up the work as best we can (although 2 developers somehow both ended up recreating the properties component!). My first piece of work has been to create a simple login dialog. To get started I downloaded an eclipse version called europa, and that has been driving me insane. When time is a factor, any little problem builds up pressure, and there is something wrong with the package explorer and cvs plugin in europa.. sometimes things just don't seem to be showing up. (sorry, I have to tell someone about it).
Anyway, other than that everything went well, using GWT is far more like programming a desktop client than a web app; control is on the client, and server calls are made to pull data when needed. For instance, there doesn't seem to be a 'page' concept, instead you add and remove panels as needed.

some progress at last

Finally up and running after the frustrations of the download process and the setup of the image, which needed some config change to expose the web services and webapp to the network. Thanks to a big effort by Alex on Saturday we finally have a system we can develop on.

On the brighter side we've had more time to read up on the GWT and the DFS both of which look very cool, like a couple of sharp looking sports cars entering the test track, will they live up to the hype or blow a gasket on the first lap.

Managed to get a simple tree working with the GWT and implementing the search service to populate it with proper docbase folders didn't seem to hard. Very cool, ajax with no javascript. Now for the trickier stuff, getting actual content across the GWT and into the repository and back again. Time for some more reading...

A very long man day

For lunch we had a delicious Pizza funghi from Ask.

impossible is nothing...

It's been a frustrating week attempting to download this D6 image. Every attempt seems to fail with a corrupt zip file. It was looking like we'd have to rename our application "5MD - Download". After trying with over 8 ftp clients, others in the team also tried and failed, however in the EDN forums people were having success, so we couldn't give up. Finally I tried attacking my 8 different downloads with 4 different compression packages and found a combination the actually unzipped the package.

So from staring at a near withdrawal from the content I'm pleased to say we're back on track, all be it, not quite where were we planning to be at this stage, but that's IT for you...

Picnic caused by download problems

Well I was going to be spending all of saturday in the office getting my man-day, or should I say person-day, worth of work completed on our entry. We had hoped to get a vertical slice of google-top working to use as a prototype to build on as we explore the new DFS API. However, Rob had problems with the download, and coincidentally it happened to be a cracking day. What bad luck :) - I had a little picnic on the lawn and read up on the DFS dev guide.

When software architects hear plans for web-service based implementations, they often start complaining about the overheads and lack of efficiency. I notice that the dev manual tries to make it clear right from the beginning that the emphasis is on SOA, not specifically web services. From the quick browse I have had so far, it looks like Documentum provide a full set of stub type classes to invoke the services, and they are clever enough that the underlying protocol can be switched from SOAP to client runtime for a local deployment without changing any consumer code. Also, they look like they have made an effort to minimise traffic with the design of their 'coarse-grained' interface. For instance, in one call we can update all the properties and relationships of a whole group of objects. It looks like we construct DataObjects, specify the new values for only the properties that need updating, and pass them all through in one go... it can't get more efficient than that! I guess we will find out soon if it is as easy as it looks.

Download failed

Was hoping to get away with a good start today but the 6Gb D6 vmware image failed last night after 3.5Gb. Kicked it off again but it needs 4-5 more hours. I guess we'll have to start by looking at the front end and the GWT.

Our first team meeting

We had our first team meeting today, seems to be more talk about how to spend the prize money than our entry. Looks like we're going to split the team and work 3 seperate Saturdays. Lets hope the 6Gb D6 Download completes okay and runs on our company network without problems, to tomorrow we can get into it straight away...

Documentum (D6) meets Google Web Toolkit (GWT)

As if building our entry in 5 days wasn't enough, we're also going to introduce ourselves to another new exciting technology, the Google web toolkit (GWT).

Welcome 5MD - gTop

Using the GWT we are planning on writing a GWT implementation of webtop with the backend being Documentum D6 technology. Obviously this is not going to be a fully functioning webtop implementation, but we thought we'd see what we can achieve in only 5 man days, that's one day for each developer in the team, hence the name 5MD - Gtop.