Debra Bellmaine

Nate,
I actually don't know of any specific links to any Sun sites that discuss MVC. You could try doing a search at their site...they do post lots of white papers, etc. The instructor-led classes are pretty expensive, but they also offer web-based courses that are much more reasonable. I'm doing one right now to study for the Web Component Developer exam.
Debra

Way to go! Very, very impressive.
Best,
Debra Bellmaine

Hugo and John,
Hugo, I'm glad that my discussion was helpful...good luck to you!
John, I actually think that the number of Models, Controllers, and Views are totally architectural issues. I can think of situations where you might have "sub-Models", each representing a data object, in a large system. And so you would end up with multiple models. I would never put all the code for Customer maintenance in the same Model as Order Entry data, for example. I think the main thing is to get the idea of the separation of church and state: the Model resides on a server (ususally) and represents the data object. The View resides on the client, and represents the user's view of the data - for that specific application. And the Controller makes sure that both are communicating in a correct fashion, but allows them to be de-coupled. Lots of ways to slice and dice when the concepts are understood.
With regard to my references to ListArry, I agree it would be better to simple refer to List or Collection, as there are lots of ways to implement. Good luck to you also on your project!
All the best,
Debra

Dean,
Stellar, outstanding! As far as I've been able to tell, there are no other 155 scores posted on JavaRanch, so this is quite something. Can you tell me something of your professional background? Are you a long-time Java programmer, or new to the language, like me?
Debra Bellmaine
SCJD

Nagu,
Thanks for the congrats. To answer your question about the table, the Fly By Night application uses only one binary file, called "db.db," which is provided by Sun and cannot be altered as to form. This file must be used for the project, and I'm not aware of anyone adding any additional files/tables to their implementation of the project - it's completely unnecessary. Hope that helps.
Best,
Debra

Eugene,
You've basically got it, although my code was split up a bit more. I declared the listener or action in the View, with as anonymous inner class, as you have. But I assigned it to an instance variable of the action type, and passed it to the GUI, where it was registered with the component. And, I had a method in View that strung together the search params in the String criteria, which was then passed to the controller(s). But, overall you've got the concept.
Debra

Hi Eugene,
No, the Controller(s) actually register themselves as listeners to the View. The Controller invokes a method in the View implementation class, passing itself as the argument, to register itself. The View stores each registering Controller in an ArrayList. When there is a user gesture (user-event), the View loops through all Controllers and notifies them. It could be that there is more than one Controller, but that only a particular Controller is interested in a specific gesture, and so that Controller will act upon the gesture notification.
I hope that this makes sense. Everything I know of the MVC pattern is from the Sun class I took, so it is possible that there have been other implementations, as the patterns are not language-specific.
Best,
Debra

Gosling, Amit, & Hugo,
As far as my enabling/disabling the tool and menu item for Book Flight, I had a ListSelectionListener for my JTable (actually it gets registered to the selection model). When the list selection changed, I queried the table model to determine what the value of "seats" was for the row, and enabled/disabled accordingly. And yes, I did define Actions for all menu/toolbar/button items, declared in the View, and passed to the GUI.
Amit, you have hit the nail on the head with regard to the lock/unlock scheme. As to defending your design decision, what I would say is this. If you are not certain about how to defend it, then you are not sufficiently certain about the correctness of your approach. Once you yourself are completely convinced as to the appropriateness of your approach, it will be easy to explain to someone else - you just simply tell them why you believe it is the right way to do it. I suggest spending some more time reading and rereading the posts in the forum on lock/unlock, LockManager, and ConnectionFactory, and draw some diagrams of how this all goes together. I don't mean to be hard, or unhelpful, but this is one of the areas where you really need to work this out yourself so you have certainty.
Hugo, with regard to the View directly invoking criteriaFind on the Model, you could do this, however the Sun approach was to have the View inform the Controller of all user gestures, so that the Controller could decided how to deal with the gesture. As the name Controller implies, it is intended to be a control point for the system, almost like a traffic cop between the Model and View. I went ahead and split it out this way for this reason, although in truth it does add more methods and code to have the View notifiy the Controller, then the Controller tells the View to do such and such, etc. However, when you consider a much larger application, perhaps a multi-user accounting system deployed over a network in a medium to large business, there will be lots of different Views and Controllers all in that one app. One View may deal with Purchase Orders, and the other handles Accounts Receivables. By creating a real dividing line between the Model, View, and Controller, each piece is more readily extended when enhancements are requested, without affecting the others, and that addresses one of the other project requirements:

Your user interface should be designed with the expectation of future functionality enhancements, and it should establish a control scheme that will support this with minimal disruption to the users when this occurs.

Happy coding,
Debra

Hi Eugene, Gosling, Amit, Cindy,
First, I have to apologize. I have egg on my face. In reviewing my FBN code, it does not exactly conform to the diagram above in that I removed the code that registered a View listener with the Model.
In the classroom project that we did, Sun had used the Observer/Observable pattern (but not the interface or class) to allow the Model to immediately notify all Views of state changes. I really thought this was cool, and wanted to do this, but was discouraged by some wise JavaRanch participants, as the specs definitely state that this is not necessary.
If I had implemented FBN exactly per Sun's example of MVC, I could then explain that the manner taught by Sun of enabling communication between the View and Model when implementing the MVC pattern architecturally is thus:
1. When the View is instantiated, it is passed a reference to Model, which it stores in an instance variable for later use. If View needs to invoke methods directly on Model, it uses this value to reach the Model.
2. When the View's constructor is executing, it uses the Model reference to invoke a viewListenerRegistration method, passing itself as an argument. The Model would store the reference in some type of Array. When later some state changed in the Model, it would invoke a method in itself that would loop through the Array and notify all listening View's of the state change, so that they could respond or not, as each View decided.
As it happens, I took out all the state-change notification logic from FBN, including the code where the View registered itself with the Model. I do still have the Model reference stored in the View.
Now, as to when my View invokes methods directly on Model. In my implementation it currently does not, but I still need the reference as this would very likely change as FBN was extended into a more full-function travel service.
In order for the data presented by View to be updated, there are two ways it can get the info. It can "pull" the data by querying the Model, or data can be "pushed" to the View by Model or Controller. If you look at the diagram again, you see the line where Model notifies the Views of a state change, and this notification might, or might not, include the new data. If it only informs View that there was a change, View will have to query Model to actually update the data it is presenting. Similarly, when Controller directs View to give a particular presentation, it might pass the data to View, or it might just tell View to show window X, and it is then up to View to get the most current data for the population of window X.
In the case of my FBN implementation, the Controller passes ("pushes") the data to the View, so View currently gets away with not having to directly query Model, but who knows in the future when FBN is extended?
Amit, I will address your question on lock/unlock and the modify/enhance issue. First, bear in mind that 2 of the 4 points I lost was on the Server, so I didn't get a perfect score in this area. Second, I would not be helping you if I tell you how to answer the essay question. But, I will tell you some of the thoughts I had on this:
1. I didn't get to write the original Data class, but I had to use what was already there, although clearly (per the specs) it is not implemented code as it is given to us for the FBN project. As such, I considered that Data was fair game to be changed, and that this was the simplest way to accomplish what was needed.
2. I didn't think the client should have mode-specific code after startup. It shouldn't care about which mode it is in, but always do the usual actions of lock/read/update/unlock.
3. The lock and unlock methods aren't actually empty, they are just implemented elsewhere, in my case, in LockManager. There's got to be some workaround here, because the specs tell you to only allow the locking client to unlock a record, but the method signature does not allow the passing of any client identifier. Some people have selected to modify the signature, but I liked the elegance of combining the ConnectionFactory concept with the need to identify the client uniquely for lock/unlock.

Also, I didn't defend my GUI. I've been developing GUIs for 12+ years, and I thought my FBN GUI was pretty slick. It was intuitive for the user, asthetic, and efficient to use, so I figured that if the examiner couldn't see all that, I hadn't really accomplished what I consider to be the main point of a GUI: to allow a user to easily and comfortably be in communication with the computer, and enjoy the tasks he needs to perform.
Hope that helps. I didn't understand anything at all about ConnectionFactory or LockManager until a few weeks ago, but there was a lot of help to be had on the Developers Cert forum. (And I always checked on the score of those giving advice - I like to listen to the ones who demonstrably know their stuff.)
Cindy, I believe Gosling has already addressed your questions regarding the unlock issue. I agree with his assessment.
Good luck everybody. It was really fun doing this assignment, and I took Peter's advice and really wrung from it all the learning that I could. Before I did this, I knew Java syntax, but I didn't really feel that I knew how to build a system. Now I now how to approach this, and I have much more confidence in my level of expertise. The other thing I really learned was how to learn how to use the various classes provided in the JSDK. I must have spent 3/4 of my time studying the Platform API Spec online. There really are a lot of very interesting classes and interfaces of which we can make use.
All for now,
Debra
SCJD

Scott,
Way to go!!!
Best,
Debra Bellmaine
SCJD

Sam,
Also, feel free to ask all the questions you want. I got so much help here at JavaRanch, it's the least I can do to turn around and help others.
Debra

Sam,
My specs said the following:

The user should be able to select the origin and destination of flights, and the display should update to show only flights that satisfy those criteria. The user must be able to describe enter the string value "any" for the origin, destination, or both, so as to implement a wildcard-like feature.

If this is the same as your specs, then you must allow the user to specify both origin and destination. My decision to also include carrier was based on the example given in the specs:

"Carrier='SpeedyAir',Origin='SFO'"

This appears to contradict the other reference, but I figured what the heck, why not just do it all? Makes the GUI more interesting, and is more realistic.
Debra

Great job. What a score!
Debra Bellmaine
SCJD

Sam and Hugo,
Sam's question first:

I have a question about GUI design,It seems you got all score for this part. Did you use one Frame to show your Searh criteria (combobox),result and booking ? can you give us a hint? thanks.

I had one JFrame, with a menu and toolbar. The frame contained a JSplitPane. The GUI components for specifying Origin, Destination, and Carrier were in the top half of the split pane, along with a Search button. The bottom half of the split pane contained my JTable. When the user has selected a flight in the table that has seats available (seats > 0), the Book Flights tool and menu items are enabled. Selecting Book Flights brings up a JDialog, in which all the flight data is again displayed and the number of seats can be specified by the user.
Hugo's question:

I would like to have your advise on two things. Did you implement a thread cleaning up locks of dead clients? And also, did you use a rmi code base? Or did you provide de sub and the interface in the client jar?

I did implements a thread to clean up dead locks (defined as locks older than 10 seconds). This is implemented as an inner class in the LockManager class. I did not use RMI code base, I started the RMIRegistry from within the code, and I did put the stub and interface in the client jar. I also had a server GUI, but it's only function was to provide graceful shutdown of the server. I used the command line to pass arguments at startup.
Debra

Eugene,
I took Sun's Java Programming Language Workshop (SL-285), which is the course where MVC is taught for Java. The classroom project was very similar to FBN, and I modeled my implementation on what I learned in that course.
For my app (and the class project), the class that starts up the FBN system does three things:
1. Get a reference to a Model (either remote or local, since we have to go either way).
2. Instantiate a View, passing the Model reference to the View constructor, as the View does state queries against the Model directly.
3. Instantiate a Controller, passing the Model and View references to the Controller constructor.I'll try to recreate the MVC diagram that I learned in the Sun course:
|----------| State query | | ---------->| Model |<------- | - - - -| | |State | | |----------| |Change | | | | | Change | | v notification | |-----------| |-------------| | |<---------------| | | View | View selection | Controller | | |- - - - - - - ->| | |-----------| User gestures |-------------| The line going from Model to View, noted as
"Change notification," is the Model firing a notification of a state change to all registered Model listeners (Views - can be more than one, stored in an ArrayList). The line going from View to Controller, noted as "User gestures," is the View firing a notification of a user-event to all registered View listeners (Controllers - can be more than one, stored in an ArrayList).
View directly can invoke methods in Model to query the current state, and Controller can directly invoke methods in Model to initiate a state change. Controller can also directly invoke methods in View to direct the View selection.
From this you can see that View must have a reference to Model, and Controller must have a reference to both View and Model. Model does also have a reference to all listening Views, for the purpose of change notification, and View likewise has a reference to all listening Controllers, for the purpose of user gesture notification.
I suppose that the View and GUI could be combined, but a GUI is inherently sufficiently complex that it is a better approach to split out the GUI from the View, and reduce the degree of coupling between objects. For example, I could completely redesign the user interface without making any change to the View code.
Incidentally, each component of the MVC implementation is an Interface, with a corresponding implementing class.
To answer your question:

What happens if the GUI control that holds the value changes (say from combo box to text field? That will mean that both the GUI and the view will have to change, right?

The View doesn't care what values the user specifieds in any of the JComboBoxes until the user hits the Search button, toolbar item, or menu item. Then the View invokes the methods in the GUI to determine what the current selection is in each combo box.
Regarding the last point about my Model interface being implemented by Data, again this was the example used in Sun's class. Their definition of Model is:

Represents the application data and the business rules that govern access and modifications of this data.

That's pretty much what the Data class is already doing, so I just created an Interface, and away I went.
Hope I have answered your questions...rereading my answers, they sound a bit professor-ish, but since I had the benefit of Sun's official viewpoint on MVC, I thought it might be helpful to others.
Best,
Debra
[ July 01, 2002: Message edited by: Debra Bellmaine ]