Benz Blog

This one is courtesy of Delphi 2009 (which appears to allow undoing past save! WOO HOO!).

It’s amazing how bad this shit is. I mean look at this crap – all I was trying to do was to copy a file from a local drive to a network drive, using Windows Explorer, and I get this:

I eventually realized it was asking me – in general – if I wanted to move or copy files, not to select move or copy. So it should have asked “Do you want to enable moving or copying of files from this zone”, or something similar.

Millions of dollars in usability testing and this is what we’re left with. Sad.

The “zone” thing, too, is confusing. I honestly have no idea what the hell they mean by zone in this context.

I should come up with a commercial to counter the “I’m not cool enough” anti-Apple ad: “Guess I’m not dorky enough to understand this crap”.

Absolutely brilliant error message:

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