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.
|
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
