NX:why the client mode cannot update the Jtable?

[frank sun]

Hi,
When the program running in the standalone mode, it can update the Jtable with the result in time.
But when running in the client mode, it can get the result from the server, but cannot update the Jtable, and I found that the method getValueAt in TableModel was not called everytime.
Please help!
Best regards!
Frank!

[frank sun]

I guess it's because of the swing components could not support the serialization fully, the below is from the JDK help doc:
Warning: Serialized objects of this class will not be compatible with future Swing releases. The current serialization support is appropriate for short term storage or RMI between applications running the same version of Swing. As of 1.4, support for long term storage of all JavaBeansTM has been added to the java.beans package. Please see XMLEncoder.
In my client gui design, I create the view which extends the JFrame, and assemble all other components(eg, JTable) together in this class,
But, if I create another client gui builder, which does not extends the JFrame, and implements the seriazable interface, will it be OK?
Expecting for your comments!
Best regards!
Frank

[Andrew Monkhouse]

Hi Frank,
I am very confused here.
Your last post reads as though you are generating the JTable at the database and sending it over RMI.
You should not be sending swing components over the RMI network. The database should be just that - a database. No graphics or anything else. Then you add RMI to allow you remote access to the database. Then you add the client which gets the data from the database and displays them (using swing). Therefore the swing components do not get sent over RMI.
If you are only sending data over RMI and creating the JTable in the client, then the only thing I can think of is that your application must be aware of whether it is local or network mode, and you are running different code dependant on mode. This should not be. Your code building the JTable should only know that it got data. Fullstop. It doesnt care where the data came from. It is up to you to make the network code behave the same way as the local code so that this can happen.
I hope that one of these comments has helped you to work out the area in which your code is going wrong.
Regards, Andrew

[frank sun]

Thanks first!
I think I didn't make my question clear,
actually, the search result and window could display in the server side, while not in the client side.
I register the Client to the server when creating the window, and after the server execute the requested method forwarded from the controller, it executes the method fireModelUpdated, which wanna to force the registered client to update the data.
the code snippet here(the design comes from this forum of MVC thread):
Iterator iter=listener.iterator();
while (iter.hasNext()) {
((ModelListener)iter.next()).modelUpdated(notifyType, data);
}
I think it's because the registered client is seriazed in the server side.
(I changed the Client class, it does not extend the JFrame, but the problem is still.)
Please!
Frank.

[frank sun]

I think, the real question is, how to let the remote server notify the local client to update it's view through RMI?
Please help!
Frank

[Andrew Monkhouse]

Hi Frank,
I am still confused. This is a normal condition for me though
Normal situation for a Model-View-Controller is:
Model represents enterprise data and the business rules.
View displays the data
Controller sends commands from the View to the class that has to act on it (normally the Model)
Take a look at the Sun Model-View-Controller blueprint for a more detailed description.
It is normally the model which has to update it's views when the data it is modelling changes.
Take a look at the Observer and Observable classes - you seem to be duplicating their functionality.
Now for our purposes, the Model is connected to the Database. Whether this is through a direct connection or via RMI is unimportant. All we (or the model) cares about is that it is connected. And all it is doing is providing access to the data - it does not know anything about how it should be displayed (screen, printer, wap device ...)
All we need to do for the assignment is get the data from the database that is current at the time of the query. We do not have to worry about live updates.
It would be possible to handle live updates, however this is outside the scope of the assignment. If you are really interested, look at Sun's Fundamentals of RMI Short Course which describes "RMI Client-Side Callbacks".
So to answer your question:

how to let the remote server notify the local client to update it's view through RMI

The answer: we dont. The model does a query to get the data (either direct connect or RMI) and gets the data in an immediate response.
The model then sets its changed flag and notifies observers.
Regards, Andrew

[frank sun]

Hi,Andrew
First, thanks for your fast coments.
In the below code snippet, it is written in the Model, and it tries to call the Client view's method modelUpdated, but it is RMI, that means it tries to call back to the view through RMI, I thought that's problem.
===========================================
Iterator iter=listener.iterator();
while (iter.hasNext()) {
((ModelListener)iter.next()).modelUpdated(notifyType, data);
}
============================================
The model wanna to "Push" the update to the client view through RMI, if so, the client view should also implements the Remote. this is not good.
So, If we use the "pull" to get the update from the model, there will be no this problem, but I have no idea how to implement this.
Could you show me some code snippet sample of that?
Best regards!
Frank

[Andrew Monkhouse]

[BARTENDERS: Please let me know if this is getting too close to providing a real solution).
Hi Frank,
You said: the ... code snippet, it is written in the Model, and it tries to call the Client view's method modelUpdated
Please see my earlier comments about using standard Java - look at Observer and Observable in your API documentation. You may have to rethink how you send data, since you cannot send 2 parameters using the standard APIs, but the plus side is that most of the support methods will then be written for you, and it is a standard.
OK, so your Model has received the update, and is trying to pass it to the View - this is good.
But I have a problem with but it is RMI, that means it tries to call back to the view through RMI
Are you saying that your Model is actually on the server? If so, then I believe it is wrong. The model should be in the client application.
You asked: Could you show me some code snippet sample of that?
I dont think we are at a point where I can give a code snippet - I get the feeling that we are still at a point where we should be discussing concepts, not implementation.
So here is my conceptual way that you might meet the requirements. Note that this may not be the best way of doing it, and any class names etc., that I use are done just for descriptive purposes - I probably wouldnt use these names in real life. This concept is just to get you to a point where things might start working again - it almost certainly will have to be modified substantially to meet the requirements of the assignment.
Sun instructions: Your data access class must be called "Data.java", must be in a package called "suncertify.db", and must implement the (DB) interface
(I went to the sun site today, and downloaded the assignment and got the Hotel assignment ). I am going to keep going with FBNS though, as I have just finshed getting everything working properly, and only have documentation to finish.
So you create your "Data" class which does the above, and only the above.
You then create a class (DataRMI) that provides these same methods in an RMI way.
On the client side, you create a class (ClientRMI) that will do a lookup for the functionality that DataRMI provides, and wrap it's methods for you.
Your Model can then call ClientRMI, or Data directly - both will provide exactly the same methods with exactly the same return types, and exactly the same exceptions.
So your model can call the find(String[] criteria) method no matter whether it is using RMI or direct connect - in both cases it will get back the int array. It can then do whatever processing it needs before sending the update to the view.
Then there is never a need for the server to try and push the data over to the client - it is always the client doing a pull of the data from the server.
Regards, Andrew
[ May 07, 2003: Message edited by: Andrew Monkhouse ]

[frank sun]

Hi,Andrew
Thank you so much.
I will rethink my design and post my questions here later.
Thanks again!
Frank

[Max Habibi]

Originally posted by Andrew Monkhouse:
[BARTENDERS: Please let me know if this is getting too close to providing a real solution).
[ May 07, 2003: Message edited by: Andrew Monkhouse ]

I think you're fine here Andrew: this is all conceptual, really.
M

[frank sun]

Originally posted by Andrew Monkhouse:

Sun instructions: Your data access class must be called "Data.java", must be in a package called "suncertify.db", and must implement the (DB) interface
So you create your "Data" class which does the above, and only the above.
You then create a class (DataRMI) that provides these same methods in an RMI way.
On the client side, you create a class (ClientRMI) that will do a lookup for the functionality that DataRMI provides, and wrap it's methods for you.
Your Model can then call ClientRMI, or Data directly - both will provide exactly the same methods with exactly the same return types, and exactly the same exceptions.
So your model can call the find(String[] criteria) method no matter whether it is using RMI or direct connect - in both cases it will get back the int array. It can then do whatever processing it needs before sending the update to the view.
Then there is never a need for the server to try and push the data over to the client - it is always the client doing a pull of the data from the server.
Regards, Andrew
[ May 07, 2003: Message edited by: Andrew Monkhouse ]

So, does the ClientRMI is also a Remote Object located in the Client side, and it forwards the model's request to the DataRMI? but why should the ClientRMI be a Remote object?
Sorry I am not clear about your idea.
Please help.
Frank

[Andrew Monkhouse]

Hi Frank,
No, ClientRMI (definatly a bad name for my class ) is a class that is always on the client side of the network.
Think about what you want your model to do in order to display the selected records (it will do far more but this should serve for the example). It needs to call the find method and with the result of that it needs to call the read method as many times as necessary to get the records.
If you have a direct connection, then you could be calling the Data.find and Data.read methods directly.
Now the DataRMI class I suggested gives you the same methods, so it is tempting to have your Model just do the RMI lookup to get a reference to DataRMI and use it's methods directly.
Do you understand the concept so far? If not, stop here and ask questions before we move on to the next bit.
Still here? OK, the concept behind the ClientRMI class is that it gives you an extra layer of abstraction. All you want the Model to do is to Model the data. You do not want to be adding code to it to handle the different exceptions you might get from a Direct Connection compared to an RMI Connection compared to an MQ Series connection compared to .....
The ClientRMI class starts you towards that abstraction. The ClientRMI class has all the same methods as the public classes in Data (or in DataRMI) but (and this is the important bit) it hides the fact that the connection is via RMI. The way it does that is by wrapping the calls to the DataRMI within it's own methods of the same name, and whenever something happens that is RMI specific it either handles the problem itself, or throws a new Exception that the Model can understand in a generic way.
Again, if you dont understand something, stop and ask questions. The following builds upon the previous....
Of course, once you have abstracted the RMI connection in this way, you should also abstract the direct connection in the same way.
And now that you have abstracted these connections like this, it would be nice to have a standard way of accessing these abstracted methods in a way that would allow future growth with little (or no) changes to the Model. And then we get to the Factory Pattern.
Woo hoo - we are using another pattern in our application, and it wasn't even contrived - it fits in nicely
Regards, Andrew
[ May 07, 2003: Message edited by: Andrew Monkhouse ]

[frank sun]

Thank you,Andrew.
From your idea, I feagured it out.
Best regards!
Frank