Re: Pure Swing JavaClient distribution channel
Re: Pure Swing JavaClient distribution channel
- Subject: Re: Pure Swing JavaClient distribution channel
- From: Florijan Stamenkovic <email@hidden>
- Date: Wed, 9 Nov 2005 15:42:22 +0100
Hi,
Thanks a lot! It took me some trying to set it up, but it is running
fine. I did exactly as you described, only I changed the bindings in
the JavaClient component a bit more (just to indicate NO class bundle
downloading, as the only traffic I want to have is data and RMI), and
made a different construction in the Client project. I left the
AppName.java file to be the main class of the app. In it's main() it
displays a modal window for getting the app URL, and it then invokes
EOClientApplicationSupport.main() with the supplied URL as
-applicationURL argument. In finishInitialization() I create and
register a JFrame, in which I then fetch and play with data. All goes
fine.
As for EOF, yeah, there is already a lot there, and I will try to see
what I could use. It is a fine framework to use (from my experience
with WO), although a bit big to tackle at first.
I checked the API on EOAction, and it extends AbstractAction, which
implements Action... So, you should be able to just feed it to a
JMenuItem's constructor... Did that not work? Did not get around to
checking it out yet. We however do need menus, and I will get around to
production shortly... If I find something interesting, I will let you
know. At the moment I have no clue what the benefits of an EOAction
are. Have a lot of API reading ahead...
Again, thank you. You saved me some painstaking EOF exploration. And
you even get a kiss from my boss :) This were a barrier for us, as we
have experience with Swing and EOF, but not combined...
Best regards,
Flor
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?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden