Cocoa and ODBC

Its being a long time I have not come here to write... and it has been a long journey since a nice tool come to the desktop to connect a relational database with Cocoa (inside OSX). Since the introduction of the Core Data framework, some years after the deprecation of Objective-C version of EOF, it became a bit of a nightmare to connect an app to a Relational Data Base (as may be Sybase or Oracle)... some attempts to rewrite EOF has been done, e.g. in Alex' Open EOF by Martin

The aim of this new attempt is to use the following mixture: The Odbc Framework is a Cocoa framework providing access to ODBC data sources. It works on top of the iODBC Framework which is a widely portable C-oriented framework that follows the ODBC specification (Open Database Connectivity). The Odbc Framework includes a Cocoa Core Data Persistent Store for Odbc, which will be used here. And finally, we will use as persistence the proposed database Mimer SQL  (: which has a free version for developers :)

No Tiger on my Aluminum MacBook

I cannot be live it... there is no version of Tiger which runs on my new MacBook Aluminum...

Sometimes Apple take decisions I really do not end to understand...

I had tried all small tricks I know, with out success... even tried Parallels 4, but it is explicitly forbidden to run Tiger on it...

shame on Apple

AJRDatabase; Leopard Vs. Tiger

More frustration...
the EOModeler of Alex was done in an old OS X version and uses some methods which had been deprecated in 10.4 (e.g., the NSFont method - (CGFloat)widthOfString:(NSString *)aString); even though it compile in Tiger, it does not in Leopard. So, I will have to debug his code and "repair" it before I can compile-and-run it into Leopard.

no GDL2 on macports

I was able to install all dependencies of GDL2, but GDL2 it self... macports was unable to load it from nowhere...
also, I'd try to run an app from gnustep (Grom to be precise) and it simply did not started...

...all this GNUstep thing was driving me crazy, so I went to my office at ENSA and start all over, but in my Tiger Server (10.4.11)... there the history was completely different: instead of using macports, I downloaded directly from GNUstep ftp server gnustep-make, gnustep-base and gnustep-dl2, apply a couple of patches provided by Adam Fedor (Mil Gracias ;^) and now GDL2 is installed...

NeXT Step: learn how to integrate it with Cocoa...

GNUstep DL2

At the same time I am trying ARJDatabase in the office, I am trying to install GNUstep-DL2 into my PowerBook; however, several errors had occurred —I wonder why all these open projects are so difficult to make...

One needed step is to install gcc42 (I am using macports for that) but it hangs, for hours, while it displays

--->  Building gcc42

... so far, I'd just found the following comment which encourages me to wait until tomorrow before killing the cc1 process running behind the scene...
(a ticket of macports)

OpenSource EOF

So long without writing here... but this nightmare took me too much of my time...
In the meantime I had been learning and applying the so called DNA Computing; interesting , but not the aim of these lines.

I found an open implementation of Apple's Objective-C EOF in SourceForge.net... it includes source for an EOModeler, for some Adaptors, and for the frameworks EOAccess and EOControl. Even I am missing the EOInterface layer, that may be replaced with Cocoa Bindings... hopefully!

Calculator.java revisted

As discussed yesterday, while implementing the CalulatorService, doubles are not good enough for precision —see the following lecture recommended by Ken Anderson: Floating point.

To fix this problem, the first thing to do is to re-implement the Calculator.java object to accept and return strings, instead of doubles, and operate with BigDecimals:

import java.math.BigDecimal;

public class Calculator extends Object {

  public static String add(String addend1, String addend2) {
        
        BigDecimal x = new BigDecimal(addend1);
        BigDecimal y = new BigDecimal(addend2);
        BigDecimal z = x.add(y);
        
        return z.toString();
  }

Re-make the stubs and then, re-implement our CPO.m to use, also, strings:

@implementation CPO
- (IBAction)add:(id)sender
{
 id x = [[form cellAtIndex:0] stringValue];
 id y = [[form cellAtIndex:1] stringValue];
 id z = [CalculatorService add:x in_addend2:y];
 
 [[form cellAtIndex:2] setStringValue:z];
}
@end

I wonder... how does types travel through the Web Service protocols?
Let us find out...

Consuming Calculator.java WS

A well-known example, which is included in /Developer/ADC Reference Library/documentation/WebObjects/Web_Services/Web_Services.tar.gz, is a simple Calculator. To publish it is as simple as compile and run... however, to consume it inside Cocoa requires some extra knowledge; let us focus on the add method —the rest is completely analogous.

Once the service is running, the first step is to produce the "stubs"; this can be done using the command-line argument

Szamitogep# /Developer/Tools/WSMakeStubs
   -x ObjC
   -name Calculator
   -url http://localhost:4210/WebObjects/
      Calculator.woa/ws/Calculator?wsdl

which generates two objects: WSGeneratedObj.m and Calculator.m

Include these objects in a new Cocoa App project. Run Interface Builder by double-clicking the MainMenu.nib icon and, in the classes pane, create a new object, say CPO, with an NSForm *form outlet and an add: action. Create files, instantiate and connect. (of course I am supposing that you know how to do these =:o)

In the implementation of the -add: method, write the obvious line:

[[form cellAtIndex:2]
    setDoubleValue:[[CalculatorService
               add:[[form cellAtIndex:0] doubleValue]
        in_addend2:[[form cellAtIndex:1] doubleValue]]
                   doubleValue]];

compile and run... you see?
It does not work!!

The problem is in the implementation of the -resultValue method of the object add:WSGeneratedObj (defined in Calculator.m, and generated by WSMakeStubs). If you change that implementation line from

return ... objectForKey: @"addReturn"];

to

return ... objectForKey: @"ns1:addReturn"];

it will work...

But, how to find out the correct key to use?

Simple... just before the return line of the -getResultDictionary method, inside WSGeneratedObj.m, add the line

NSLog(@"getResultDictionary>fResult = %@",fResult);

and bingo!

Finally, just for the record: I used this service to add 3.4 to 6.6... can you guess the result? Wrong! Sadly, my computer, a G4 Mac mini, does not know how to add... it brings as a result

9.999998099999999

Intel inside: first view

I'd just acquired my first Intel Mac; a modest 17" super iMac running a 2 GHz Xeon. My first surprise was to find Xcode 2.4 with WO included. My second surprise was to find out that Cocoa EO remains there; even more surprising was that, by importing and compiling an "old" Cocoa EO project, the app simply runs... this means that the Java Bridge remains there which implies, by the way, that I can slow down my discovery on how to replace it.

The bad news is that new projects —created inside the Intel machine— does not compile (yet) in a PPC machine... I am not sure about the reasons, but I will find out!

For the record: to start a new Cocoa EO app inside this new machine was not straight forward. Here the steps to accomplish this.

1. install Xcode and WebObjects.
2. run Interface Builder and import the EnterpriseObjects.palette (which is inside /Developer/Extras/Palettes).
3. create or import an EOModel.
4. in Finder, go to

/Library/Application Support/Apple/Developer Tools/Project Templates/Application/Cocoa-Java Application/

and change the extension of the file —indeed the folder— CocoaApp.xcodeproj to .pbproj .
5. run Xcode and create a new project of type
Cocoa Enterprise Objects Application
and follow the wizard's instructions.
6. define your interface and add your code.
7. compile and run.

One more thing... for me was more convenient to change a Preference: in the File Types pane, change the folders>wrapper>wraper.eomodel to be edited with EOModeler (which is inside the folder /Developer/Applications/WebObjects/).

Suerte!

What's NeXT?

The next step to successfully use Web Services to substitute Cocoa EOF is to publish into a service an EOEditingContext. In this way, Core Data should be able to use EOF, via those services offered by the Editing Context, as a persistence media.

I am not quite sure where to put the line (the service); on top of the Editing Context? or, even below it?
To transfer Enterprise Objects? or, shall I transfer Dictionaries?... it will depend in the performance... we will see.

By the moment, the idea is to have, in the server side, the persistence mechanisms offered by EOF; and in the client side, a Cocoa app running Core Data to manage Display Groups and all the consistency necessary in a complex db-model. For, the model will have to be duplicated in the two formats: .eomodeld and .xcdatamodel ...

... welcome to a new nightmare!