Benz Blog

Today was the day when I feel that I “got” RemObjects. Below is an email that I sent to a colleague (Ed) which turned out to be correct:

Since migrating to a tree control, I no longer have the need for a ClientDataSet. Instead, I am populating the tree control directly as I iterate the XML returned from DocuShare.

Joe has just emailed me a sketch of the UI he is looking for, which involves separating out the collections from the documents. The collections will be the only items in the tree view, with a grid being used to display each collection’s documents. So now it looks like I’ll be using a ClientDataSet again just for the document list.

I spent 5 min going through the RemObjects SDK web site just now, and I think a light bulb just went off in my head (and I apologize here in advance if you guys have described this already and I didn’t get it on the 1st pass). Please tell me if I have anything wrong….

First, a quick recap: I’ve been building the DocuShare layer as a component with methods like “UploadDocument”, “ListCollection”, etc. The client of that component is currently my form in my proof of concept app. This means that the ugliness of the returned XML is partially exposed to the client (in the form of an interface used to iterate that XML).

Enter RemObjects. Even before I start using RemObjects, I believe I should create a higher-level component that encapsulates the DocuShare component, and hide all the ugliness there. The methods of this component will eventually become public interface to the RemObjects service. This service could then define the format of the data returned to the client, completely hiding any details of how I communicate with DocuShare. I could also potentially expose the RemObjects service as a true SOAP-based Web Service, and therefore achieve most of the advantages we thought we’d get by building a Java-based web service to talk to DocuShare instead of using it’s XML/HTTP interface. The problem I mentioned this morning will still exist, though, but I’ve got that covered.

Does this sound right?
—————————————-

Ed’s response (hope he doesn’t mind):

Your light-bulb moment is accurate. What you’re describing is a DAL (DocuShare Abstraction Layer) and is spot on. This is exactly how we treat our DAL (Database Abstraction Layer) and it simplifies things greatly on the client. Let the server do the heavy lifting and keep the client nice and lightweight.
—————————————-

to which I replied:

Benz is gettin’ excited!