Re: Pure Swing + EOF distribution channel

Hi Pierre,


Well, besides SSL and the way some arguments are passed and where, it =20=

seems we are doing the same thing. OK, I do like the approach in which =20=

you have another class (MainApplication() ) to be the actual app =20
interface. I am not sure however what might be lost with it, as you =20
loose the reference to your EOApplication subclass in your =20
MainApplication, right? I am not sure if that matters much, as I am new =20=

to this approach, and this part of the EOF in general.

At the moment I am experimenting with the AppServer project. I am =20
stripping it of all that it does not need to be a back-end for the =20
JavaClient. That so far included:

-WebServer target
-DirectAction.java
-Main component
-changing some properties NOT to start up the app in the browser, and =20=

NOT to start up the client app automatically on startup

Basically I want to block all access to WebStart. And see exactly what =20=

I need on the AppServer itself, and what not. On the Client side I were =20=

referencing but not copying ClientSide EO classes from the App Server =20=

project (as that is where they are generated), and that part goes fine =20=

as well. There is one thing bugging me, and that is type casting. It =20
seems to me the distribution channel takes care of translating the =20
Server side EO classes to the Client side EO classes. What confuses me =20=

a bit, because I saw in JavaClient documentation the approach of making =20=

a common superclass to those two classes. But that maybe has to do with =20=

non-key methods and RMI. Have to look into it. Any thoughts there?

Oh, and one more thing I am trying to get to is to see what are all the =20=

possible arguments that EOClientApplicationSupport can accept. Didn't =20=

find it in the API for the class though...

Flor


My EOApplication ClientSide class, also the main class of the app:


public class JCTestClient extends EOApplication {
=09
	/**
	*	The main function displays a modal window to ask for the =
WebObjects
	*	application URL. After that it just invokes the
	*	=20
com.webobjects.eoapplication.client.EOClientApplicationSupport.main(args=20=

)
	*	with the -applicationURL [+ modal acquired String] as =
it's arguments
	*/
	public static void main(String[] args){
		//get the URL from a modal window
		String rVal =3D new =
JOptionPane().showInputDialog("WebObjects =20
application URL:");
	=09
		try{=09
			//connect to the app
			=
com.webobjects.eoapplication.client.EOClientApplicationSupport.main(
				new String[]{"-applicationURL", rVal});
	=09
			//after this the EOClientApplicationSupport =
class takes over. That =20
class
			//however has a binding (on the AppServer side) =
that defines THIS
			// (JCTestClient) class as the main application =
class, so the focus =20
is
			//turned back here. Only in =
finishInitialization(), once all the =20
connecting
			//is established, can we starto create frames =
and invoke logic. At =20
that point
			//the control is back here in our hands.
		}catch(Throwable th){
			new JOptionPane().showMessageDialog(null,
				"Failed to connect to application...", =
"Error!",
				JOptionPane.ERROR_MESSAGE);
				th.printStackTrace();
				System.exit(1);
		}
	}
=09
	protected void finishInitialization(){
		super.finishInitialization();
	=09
		windowObserver().registerWindow(new AppFrame());   //a =
test frame =20
that does some fetching
	}
}



> Your are welcome.
>
>
> Seems what I did is different (may be not everything is mandatory)
>
> 1) in the main.wo, I add a WOJavaClientApplet
> with bindings like this
> {
> applicationClassName =3D "mypackage.MyAppAdmin";
> height =3D 512;
> width =3D 512;
> }
>
> 2) on the client side mypackage.MyAppAdmin.java
>
> public class MilapiAdmin extends EOApplication {
>
>    protected void finishInitialization()
>    {
> //    super.finishInitialization(); // il faut eviter le comportement =20=

> par defaut
> // support for ssl
>      Security.addProvider(new =
com.sun.net.ssl.internal.ssl.Provider());
>      System.setProperty("java.protocol.handler.pkgs", =20
> "com.sun.net.ssl.internal.www.protocol");
>
>
>      new MainApplication(); // my real EOF application
>    }
>
>    public static void main(String[] args) {
>
>    try {
>
>     System.out.println("Attempting to contact server...");
>
>     EOClientApplicationSupport.main(new =20
> String[]{args[0],args[1],"-=20
> applicationClassName","mypackage.MyAppAdmin"});
>
>    }
>    catch(Exception e) {
>        e.printStackTrace();
>       JOptionPane.showMessageDialog(null, "D=E9sol=E9, l'application =
ne =20
> peut se connecter au serveur " + args[1] + ".\nPri=E8re de contacter =
le =20
> support." , "Probl=E8me de connection", JOptionPane.ERROR_MESSAGE);
>       System.exit(0);
>    }
>
> }
>
> MainApplication.java is the standart Java appli where you can create a =
=20
> editing context and play with the data.
> You can them start appli with :
>
> java -classpath "wojavaclient.jar;...." mypackage.MyAppAdmin =20
> -applicationURL http://myServer/cgi-bin/WebObjects/MyAppServer.woa
> Tell me if you need more details.
>
>
> Pierre
>
>
> ----- Original Message ----- From: "Florijan Stamenkovic" =20
> <[email protected]>
> To: "Pierre Gilquin" <[email protected]>
> Cc: "EOF at Omni" <[email protected]>
> Sent: Wednesday, November 09, 2005 3:41 PM
> Subject: Re: Pure Swing + EOF distribution channel
>
>
> Hi Pierre,
>
> Thanks a lot for the hand. I posted the same question to webobjects
> list at Apple and got to a solution. I am sending a part of the thread
> below (response from [email protected]. Please feel free to comment.
>
> Best regards,
> Flor
>
>
>>
>>
>> I've recently done something similar. I believe the correct way to do =
=20
>> what you propose is to create a subclass of EOApplication. Make sure =20=

>> you have the function:
>> protected void finishInitialization() {
>> super.finishInitialization();
>>
>> // call your startup code
>>
>> }
>>
>> Bind this new subclass to applicationClassName in the JavaClient =20
>> component. It's very similar to the server side, to get access to =20
>> your application object call EOApplication.sharedInstance() and =20
>> typecast it to your class.
>>
>>
>> The framework will be completely initialized after you call the super =
=20
>> function and you can do what you want. The one caveat is don't =20
>> specify an interfaceControllerClassname binding in your JavaClient =20=

>> component and do specify the EOClientApplicationSupport as the main =20=

>> class.
>> Be sure to register your windows with the EOApplication's window =20
>> observer. I believe it'll quit the program if nothing is registered =20=

>> 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 =20=

>> in the EOModel. They appear to return null all the time. The trick is =
=20
>> to create an EODataSource with the fetch name and then call =20
>> fetchObjects on it.
>>
>> Even without the nibs, XML, and rules there is a LOT to the java =20
>> client's library that you can still utilize. I'm doing something very =
=20
>> similar to you and I've found that each time I come up with a way to =20=

>> do something I discover there's already a way to do it in the library =
=20
>> with a simple function call. My biggest complaint about it is that =20=

>> the whole framework seems to assume that all the layout's are of =20
>> EOViewLayout and will try to repackage it into one if you pass it =20
>> some windows. At the very least I'd be hesitant to throw out the =20
>> EOAssociations. I've already created some classes to allow creation =20=

>> of associations with JLabel's.
>>
>> Let me know if you figure out getting menus to work based on the =20
>> EOAction's. Menu's are not required for my app but I'll be looking =20=

>> into it later.
>>
>> I agree the lack of documentation is a horrendous oversight on =20
>> Apple's part. Hopefully they'll document what they already have =20
>> before they go further.
>> Hope this helps.
>
> _______________________________________________
> EOF mailing list
> [email protected]
> http://www.omnigroup.com/mailman/listinfo/eof
>