I've recently done something similar. I believe the correct way to do what you propose is to create a subclass of EOApplication. Make sure you have the function:
protected void finishInitialization() {
super.finishInitialization();
// call your startup code
}
Bind this new subclass to applicationClassName in the JavaClient component. It's very similar to the server side, to get access to your application object call EOApplication.sharedInstance() and typecast it to your class.
The framework will be completely initialized after you call the super function and you can do what you want. The one caveat is don't specify an interfaceControllerClassname binding in your JavaClient component and do specify the EOClientApplicationSupport as the main class.
Be sure to register your windows with the EOApplication's window observer. I believe it'll quit the program if nothing is registered with it after a certain amount of time.
Some other useful startup bindings/arguments:
splashIconName
splashIconURL provides a startup splash screen based on the icon
One gotcha I've found is creating fetch objects from specification's in the EOModel. They appear to return null all the time. The trick is to create an EODataSource with the fetch name and then call fetchObjects on it.
Even without the nibs, XML, and rules there is a LOT to the java client's library that you can still utilize. I'm doing something very similar to you and I've found that each time I come up with a way to do something I discover there's already a way to do it in the library with a simple function call. My biggest complaint about it is that the whole framework seems to assume that all the layout's are of EOViewLayout and will try to repackage it into one if you pass it some windows. At the very least I'd be hesitant to throw out the EOAssociations. I've already created some classes to allow creation of associations with JLabel's.
Let me know if you figure out getting menus to work based on the EOAction's. Menu's are not required for my app but I'll be looking into it later.
I agree the lack of documentation is a horrendous oversight on Apple's part. Hopefully they'll document what they already have before they go further.
Hope this helps.
Shouldn't you still subclass the EOClientApplicationSupport for your main application class?
What happens if no UI classes are specified? Do you get an exception? Does the distribution channel get initialized?
Unless not having the NIB UI is a problem, it seems to me that you can still write your own MVC classes and your own GUI and instantiate it in the main function of the EOClientApplicationSupport subclass. The you get the benefit of Apple frameworks maintaining the complexities (if there are any) of initializing and handling the EOF framework. The API doesn't hint much at what's going beneath the surface.
Otherwise, using your method it seem you're not initializing the connection dictionary of EODistributedObjectStore prior to using it.
On 09/11/2005, at 1:30 AM, Florijan Stamenkovic wrote:
Hi,
I am trying to get a Swing application running and connecting to an EOF AppServer. I am trying to do it in a way that I have all and Swing only UI control. No nibs, no rules, no XML, all written in Swing and a part of the distributed desktop application.
The only lead Apple gives on this kind of applications is a two page how-to that describes how to make a Swing project, add the client side EOF jars, add an application URL property, and set the main class of the app to:
com.webobjects.eoapplication.client.EOClientAppplicationSupport
This approach results in the app turning all the control to EOClientApplicationSupport, which then establishes a distribution channel, but also generates the UI and sends it back to the client. As described, this is NOT what I try to achieve.
I was tampering with skipping the switching of the main class of the app to EOClientApplicationSupport, and tried to establish a connection in my own code (see below). Did manage to get a distribution channel running, made a distributed object store and an editing context that took it as it's parent, but when trying to fetch data I get the exception (below) ON THE APPLICATION SERVER project (that is running in the background so I could connect to from the Swing app).
ANY kind of help would be very welcome as the only documentation I can find on the issue is EOF API reference. Is there a way to use EOF and it's ClientApplicationSupport without giving all the control to the standard JC handling?