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!

Wow – so I’m trying to add a right-click popup menu to my tree control, and I can’t get it to work. I add menu items but they are not showing up. Thanks to one of my colleagues, he pointed out where I should be adding new menu items, and I had been adding them to the wrong place. Let’s play “Spot The Blank Menu Thingy”:

Spot The Blank Menu Thingy

Not being able to undo past a save in Delphi 2007 totally blows.

I understand that this can be explained and rationalized in the context of describing the Delphi syntax, but I still think it’s stupid:

if myVar = 1 then
doSomethingButLookNoSemiColon
else
doSomethingButDontForgetTheSemiColon;

Of course, multi-line statements must be enclosed in a begin/end pair, but this semi-colon thing is a pain in the ass. I’ll take the C/C++/Objective-C/Java/JavaScript syntax over this any day.

“Develop With Pleasure” my ass.

I was trying to create that Java Web Service to talk to DocuShare, but I’m officially punting. Spent all morning trying to get a stupid HelloWorld web service to work. Fought with IntelliJ 8.1 – at first it wouldn’t compile the generated project. So I created a new one – it compiled. Deleted everything and started over: now it won’t generate the code – something about a library that could not be downloaded. Over an hour later, I figure out how to clear this up and get the code to compile (I completely deleted ~/Library/Caches/IntelliJIDEA8X). Another hour or so spent on why the “apt” tool was not run. Apt is Java’s Annotation Processor Tool, and needs to be run to generate artifacts from annotations placed in the source code. Eventually, I discover that apt has become part of javac in JDK 1.6, so there’s no need to run it separately. I also see a “jaxws” directory in my src directory, and discover that the files I need are actually there. When IntelliJ invoked javac, it seems to have placed the .class files in the source directory. Thanks – that’s great. So I simply copied them over to the output directory and whalla – it runs.

So after all this what do I have? I have a web service that only runs as a single-threaded standalone application, with no idea how to deploy this to Tomcat, and no client to access it. I think to myself: “maybe I can just add REST support and then quickly build a Delphi client to see how it works”. So I attempt to generate WADL from the Java source file, but immediately get an error:

Exception in thread “main” java.lang.NoClassDefFoundError: com/sun/jersey/api/core/ResourceConfig

Screw this. I’m done. I know I can get this going but this is taking way too long. If I not mistaken, once I move my Delphi code to the server and access it via our RemObjects layer, I should be able to turn the DocuShare RemObjects service into a WebService, thereby opening it up to other clients. And should the need arise to support document management systems other than DocuShare, we could create a Delphi interface, modify the DocuShare component to implement that interface, create a new implementation of the interface, and then change the code to create the correct implementation for the current installation.

Now I’m off to write a web service (in Java) that will sit in between our Delphi app and DocuShare. I’ve been weighing the pros & cons: here’s the list so far:

HTTP/XML
Pros
Already mostly implemented
Very fast
Backwards compatible: probably safe for at least 5+ years

Cons
Can’t abstract out higher level functionality
Relies on search for basic collection lists

Java Web Service
Pros
Ability to define our own contract between Delphi and DocuShare
Ability to more easily talk to different versions of DocuShare or different document management systems (i.e., more flexible)
Doesn’t rely on search
Can more easily create more complex queries

Cons
May be slower
Not yet implemented
More complicated
Extra layer to maintain, and I will likely be the one to maintain it

Quick post to remind anyone that stumbles across this blog that most of what I’ve written so far is just me venting about various frustrations in trying to learn Delphi and work in a Windows (XP) VM all day long. In many cases there are decent solutions to my complaints, and other things are just things you have to get used to. Overall I’ve been making good progress over the last week or so, and I’m actually enjoying it somewhat, in spite of the fact that I don’t care much for Pascal or Windows XP.

I just returned from a trip up to NJ where I demoed what I’ve been working on to the rest of the team, and it seemed to go quite well. Basically all I showed was a grid, but everyone seemed to understand the amount of effort that went into making that grid work (especially considering my lack of experience). I’m really starting to feel better about this project.

Why oh why does this not search backwards but instead loop through case changes on the identifier currently under the text insertion caret? UGH.

Even the code complete feature of CodeRush is problematic: it’s too slow. I’ve seen things flash by my eyes that I would have wanted to accept, but I would need to slow my typing down in order to have time to accept them.

I’ve already complained about this before but it bears repeating: the fact that you can’t undo past a save totally blows. Maybe there’s a setting I’m missing somewhere.