/*
 * testUIapp.java
 */

package harbor.test;
import kewlstuff.harbor.client.Vessel;
import net.uitestapp.interfaces.*;


/**
 * @author Johnny Kewl
 * TEST 9
 * This code pulls up a client UI app from the server and starts it.
 * It demonstrates the Coherent Disintegration design pattern
 */
public class testUIapp implements I_CDunit{
    private Vessel vessel = null;
    private I_Factory i_Factory = null;
    private I_Service i_Service = null;    
    
    /** Creates a new instance of testUIapp */
    public testUIapp() {
        String harborUrl = "http://localhost:8080/harbor/service"; //location of container harbor
        vessel = new Vessel(harborUrl); //get a vessel from the harbor 
        vessel.verboseVessel(true);
    }
    
    public void runTest(){
        //No error checking to make it easy to follow
        i_Factory = (I_Factory)vessel.loadRemoteClassInst(I_Factory.class,"net.uitestapp.Factory");//load a class instance ON the harbor         
        i_Service = (I_Service)vessel.loadRemoteClassInst(I_Service.class,"net.uitestapp.Service");//load a class instance ON the harbor        
        
        Class uiApp = vessel.getRemoteClass("net.uitestapp.UiView");//load a class from the harbor
        if(uiApp != null){
            I_UiView i_UiView = (I_UiView)vessel.newInst(uiApp);
            i_UiView.start(i_Service,i_Factory,this);//INJECTION
        }         
    }
    
    //UI app asks this CD unit to close the classes when its done with them
     public void PleaseCloseClasses(){
         vessel.releaseRemoteClassInst(i_Factory);
         vessel.releaseRemoteClassInst(i_Service);
     }  
    
}

/* Notes:
 * STUDY THIS, because its showing you the design pattern that will allow you to make great
 * remote-able applications.
 *
 * The other tests are a great way to learn harbor, but remember there we testing an isolated
 * design pattern, for example just making sure that if you ever serialize an object, it will work.
 * But this little example, shows you how you will actually make an application, and you will repeat
 * the same Coherent Disintegration pattern over and over again, in all your applications.
 *
 * Before you even run this, open the application source code, the actual POJO application
 * that you will find in Harbor_UIapp_Lib.
 * As you see, its a simple little application with three main classes.
 * There is a Service object that holds a text message.
 * There is a Factory object that uses the Service object
 * There is the UI object that displays the client VIEW, and this uses the Factory, Service, and CDUnit objects.
 *
 * Now run the main class called CDTestUnit... you will see the UI open and you can type in and
 * read back a simple message.
 * Now look at the code in the POJO CDTestUnit... it looks like this...
     public void start(){
        factory = new Factory();
        service = new Service();
        
        UiView uiView = new UiView();
        uiView.start(service,factory,this);         
     }    
    
     public void PleaseCloseClasses(){
        factory = null;
        service = null;         
     }
 *
 * Can you see it controls the application... it initializes the objects, injects them into
 * the UI class, and then internally the UI class writes and reads messages using these classes.
 * There is also a callback from the UI class, so it can ask the CD unit to do stuff, like close
 * classes.
 *
 * NOW.... COMPARE IT to the code above....
 * Can you see its the same thing... and NOTE that this code above, what we call the client,
 * has got nothing to do with the UI side of the application, its the piece of code that
 * CONTROLS the application.
 *
 * NOTE also that the code above is what you put on the internet or give to someone that wants
 * to run this application... and that the code above is EXTERNAL to the POJO application.
 * In other words that full application is simply compiled and dropped into the POJO container,
 * you dont touch that proofed and debugged external code, just drop it in.
 *
 * Then, the code above mimics the tiny CONTROLLER... and its different only in that its telling
 * your application to run the UI side, on the remote client, and leave the rest running
 * in the server.
 *
 * There is one other small technical thing.
 * We have used the fancy Netbeans Swing-Layout-1.0.jar library, and naturally because the
 * UI is running remotely it needs to be on the client machine.
 * So, do you need to include it in this module, because this CD unit is whats going out there?
 * NO... you just drop the library into the Harbor repository as well.
 * In other words, to make your application run, you simply drop it and all its dependencies
 * into your Harbor, EVEN if its destined to run on the client side.
 *
 * You have probably seen this design pattern before... its MVC. 
 * If you wondering why we always call a full application, a library, and in fact develop
 * applications for Harbor in libraries, there is no reason that you have to, it just keeps
 * reminding us to develop the CD unit. Typically nothing runs in a library, unless you make
 * it run... thats why we do it, its a way of helping force one to use the MVC model without
 * getting too academic about the whole thing.
 *
 * Pojo Application CD Units (this code here) are normally made into full
 * applications... we call them ships.
 * Its poetic license... its nice to think of it as a ship that has sailed from the Harbor.
 * If you would like to see what this looks like as a ship... see the Harbor_UIapp_Ship example.
 * Its in the source code and besides being a runtime jar that one can just click on
 * to start the whole thing running, client and server side... that example also shows
 * you how to take a SHIP and launch it from the browser... which is nice, because
 * the whole design cycle comes down to... we as programmers drop the apps into the harbor,
 * the user clicks on a web page to run it.
 *
 * Now this is a *real* application server.
 */