aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes GUIContoller Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "GUIContoller" Watch "GUIContoller" New topic
Author

GUIContoller

Vlad Rabkin
Ranch Hand

Joined: Jul 07, 2003
Posts: 555
Hi,
I need again help for MVC...
Could you please verify if it is Ok to have such GUIController Interface.

1)
I am exepecially concerened if is Ok to have getDocumentMethods()?
This is the only elegant solution for input validation I managed to find,
2)
Is it Ok to have selected row (so that contoller can find a record in TableModel) in
book method.
Many tx,
Vlad
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11424
    
  85

Hi Vlad,
Are you calling these methods directly, or are you using hook / callback functions to call them?
I am exepecially concerened if is Ok to have getDocumentMethods()?

What other classes are using these Documents?
Personally I think that a Document is pretty specific to the view that is using it. The instance of the Document is not normally shared with any other view or any other class. So normally I have my views instantiate their own Document for each text field that uses a specific document.
Is it Ok to have selected row (so that contoller can find a record in TableModel) in book method.

Hmmm, this implies that the controller also has access to the table. It can work, and if you are using hook methods then this could make sense. If you are not using hook methods, then why not pass the correct row out of the view to the book method?
Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Vlad Rabkin
Ranch Hand

Joined: Jul 07, 2003
Posts: 555
Hi Andrew,
What other classes are using these Documents?
Personally I think that a Document is pretty specific to the view that is using it.

Only ClientWindow class (my main gui view class for book component and search component.) It is correct what you said, but how can I pass length information for each field to the view?
I have suncertify.db.SchemaModel class, containing all this information,
but as I understand MVC, the view shouldn't use any classes from database directly, because if any classes in data layer change, then view must be changed, and that is not good... Is it right?
It means I shouldn't provide such a method in GUIController:
suncertify.db.SchemaModel getSchemaModel()?
How can I do it then? Make a new class GUISchemaModel and let the contoller parse SchemaModel from db to GUISchemaModel???
If you are not using hook methods, then why not pass the correct row out of the view to the book method?

Andrew, I can't answer this question, because I don't know the meaning of the word "hook methods"
I don't have any callbacks if you mean it. The problem is pretty same as with Schema.
My Data layers returns record as RecordModel object. My TableModel holds then RecordModels. So, to do what you said (and that is what I have done first, but changed yesterday), my view has to first to call
record = (RecordModel) tableModel.getRow(selectedRow);
contoller.book(record);
But it means again that my view uses class from db package!
Ok, again, I could do like this: my new ClientRecord class.
So all RecordModel will be parsed to ClientRecord in C-tor of Table Model.
The View could make following:
record = (ClientRecordModel) tableModel.getRow(selectedRow);
contoller.book(record);
And Controller would parse ClientRecordModel to RecordModel to make appropriate call then to the database, but it is kind of weard (IMO).
Max has done actually this parsing in his DVDTableModel, but he didn't have to create new classes, he had String[]. Since I have id, I can avoid creating a new class.
Andrew, please help me. I am stucked with the MVC.
I really don't know how these 2 problems shoub be solved. And I believe there must be a standart approarch to them, since it is a standart problem in MVC...
Many Tx,
Vlad
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11424
    
  85

Hi Vlad,
OK, I have to admit that I am not certain what your usage of "document" is implying in the comment:

My original thought was that you were setting up a customised Document for use with the JTextComponent.setDocument() method (or, more likely, a subclass of JTextComponent).
But now you are talking about the schema, so I am not sure if my interpretation above is correct.
as I understand MVC, the view shouldn't use any classes from database directly, because if any classes in data layer change, then view must be changed, and that is not good... Is it right?

Yes, that is correct.
However that does not mean that the view cannot get the field attributes from the model. In fact, since the field attributes are static, this is one of the cases where the view can directly query the model to get that information without going via the controller.
If the database changes at a later date, the model can hide that fact, while still providing a method of finding out the field size.
Or if you believe that some future database implementation might hide the field sizes for some reason then you could set up the method in your model to return zero or throw an exception if the size cannot be returned, and then code your view to handle that case as well.
Andrew, I can't answer this question, because I don't know the meaning of the word "hook methods"

Wimpy excuse for avoiding my questions
I don't have any callbacks if you mean it. The problem is pretty same as with Schema.

We are probably both talking about the same thing when we talk about callbacks.
Perhaps you might like to look at this thread where Eugene Kononov describes hook methods as suggested by some guy named Mark Spritzler
my view has to first to call
record = (RecordModel) tableModel.getRow(selectedRow);
contoller.book(record);
But it means again that my view uses class from db package!

Don't get too concerned about this. It would be better if the view did not use classes from the db package, but this is not a critical issue. What is more important is that the view is not accessing the database directly.
If the database changed at some point, you would be able to accomodate it by modifying your model so that the data returned from the database is converted into RecordModels. None of your views / controllers would have to change. And that is a major advantage for the MVC.
As I see it, you have two choices here:
  • Modify your MVC so that all three classes are passing around generic objects
  • Leave your MVC as it is, and put a comment in your design decisions document stating that you are using your own Value-Object class (oooh, another pattern in use ) to pass data around, and if the back end database changes then the model can hide that change as I mentioned above.


  • And I believe there must be a standart approarch to them, since it is a standart problem in MVC...

    Well you know the old saying about standards ... the good thing about standards is that there are so many of them to choose from
    MVC is no different. It is a useful pattern, but there are many variations on it, and you should not get too caught up in trying to have a "perfect" MVC since what may be perfect to you and me may not be "perfect" to someone else.
    Regards, Andrew
    Vlad Rabkin
    Ranch Hand

    Joined: Jul 07, 2003
    Posts: 555
    Hi Andrew,
    My original thought was that you were setting up a customised Document for use with the JTextComponent.setDocument() method (or, more likely, a subclass of JTextComponent).
    But now you are talking about the schema, so I am not sure if my interpretation above is correct.

    You understood me correct. I use the Document JTextComponent.setDocument().
    In this case I avoid using Schema in the view. If I don't use the trcik them my view need SchemaModel from db package.
    You gave a nice idea: hide the schema in tablemodel, but my JTextField for enetering Customer ID has nothing to do with TableModel and it also needs info about max field length.
    Ok, I don't want bother you with questions. I need some time now to analyze your last reply and I will write then one more mail.
    Thank you!!!
    Vlad
    Vlad Rabkin
    Ranch Hand

    Joined: Jul 07, 2003
    Posts: 555
    Hi Andrew,
    1. SchemaModel (to know field length)
    Ok I followed I advice it is done:

    public class RoomTableModel extends AbstractTableModel {
    private GUISchema guiSchema;
    private SchemaModel dbSchema;
    private RecordModel[] rowData = new RecordModel[0];
    ...
    public int getColumnLength(String name){
    return dbSchema.getColumnLength(dbSchema.findColumn(name));
    }
    ...
    public String getColumnName(int column){
    return guiSchema.getColumn(column).getLabel();
    }
    }
    ...
    public Object getValueAt(int row, int column) {
    Object aValue = new Object();
    if( rowData != null ) {
    aValue =
    rowData[ row ].getValue(guiSchema.getColumn(column).getName());
    }
    return aValue;
    }

    I have now two schemas in TableModel: I need GUISchema to have all columns set in the way it is defined on the client. I need DataSchema to find out max length of column statically (even before any records have been found).
    I hope it is Ok and the problem is closed.
    2. RecordModel.
    Hook methods. Ok I looked at the thread. I am scared...
    The implementation of business methods such as searchFlight() and bookFlight() belongs to the Model, -- that's exactly what Model is for, -- to model the business
    neither Model nor Controller should return something like FBMTableModel or FBNComboBoxModel.

    My calls to the database are located not in the Model, but in Controller (As in Max book) and my Contoller has no reference to the view, since it is not needed. My model doesn't have actually any logic, beside set/get methods. Is it Ok? Or have to do everything as Eugene said?


    As I see it, you have two choices here:
    1) Modify your MVC so that all three classes are passing around generic objects
    2) Leave your MVC as it is, and put a comment in your design decisions document stating that you are using your own Value-Object class (oooh, another pattern in use ) to pass data around, and if the back end database changes then the model can hide that change as I mentioned above.

    Lets start with the second suggestion:
    As I don't have any logic in Model, but in Controller. It would be probably the controller, who wouch have to map the new server Record class to the RecordModel. Is it Ok?
    First suggestion: before we start discussing it, am do I understand you correct, that actually it is not so bad to have #2?
    Andrew, I am really really sorry for all these stupid questions, but it is thrue: I have no clue about designing GUI clients...
    Thank you so much,
    Vlad
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11424
        
      85

    Hi Vlad,
    You know how I mentioned earlier that there are many variations on MVC? Well, this is a perfect example. Max and I have different opinions on how the MVC pattern works - he believes the controller connects to the database, and I belive the model connects to the database.
    You can read more about my interpretation in the thread Bharat started titled NX: URLy Bird 1.3.1 Connection Factory Design. In there I also link to Sun's description of MVC, and Sun's description of View Helper (which I believe is a more accurate description of the pattern Max uses). Another link is Sun's description of how they use MVC in the Pet Store application. That diagram shows the model doing the "data retrieval" and "perform operations", and the controller just processes the user requests which are sent to the model for action.
    Regardless of what we call it though, Max's design is good and valid. It does work very well for this assignment. So don't get too concerned if you are not doing things exactly the same way Eugene is suggesting.
    Now I am going to have to revisit all my comments in this topic, and make sure that they do fit in with Max's MVC pattern.
    Regards, Andrew
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11424
        
      85

    Hi Vlad,
    Many of the comments I made earlier were based on the assumption that it was the model that was connecting to the database.
    So I think before we can go further, you are going to have to decide which version of MVC you wish to use, then we can move forward from there.
    Regards, Andrew
    Vlad Rabkin
    Ranch Hand

    Joined: Jul 07, 2003
    Posts: 555
    Hi Andrew,
    Tx for the links:
    Sun:
    Controller executes business logic in the model in response to user requests and helps select the next view for display

    Andrew:

    The TableModel is not an MVC model. It does not abstract the access to the database in any way. It is just a way of describing the table.)
    The View displays the data provided by the Model. It sends actions to the Controller, and receives data from the Model. It may receive the data through the push or pull model (where the Model may push the data to all it's views, or the Views may have to pull the data from the Model).
    The Controller translates actions from the View into calls to the correct methods in the Model. It can also do things like veryifying access rights. If you are using a Heirachial-Model-View-Controller the Controller would also be responsible for linking the Controllers together and for sending the action to the next link in the chain.

    Max:

    Well, the TableModel is the Model being created for the consumption of the GUI layer. Then the GUI does it's own MVC thing with it. Correspondingly, the DVDRecords are the Model being presented to the middle tier from the backbend tier. Thus, contrary to Andrew's interpretations, I see the TableModel as the model, which explains the Model piece in the diagram. In Andrew's interpretation, The Model is strictly what the back end manipulation as a logical abstraction between itself and the database

    Ok, now I understand that TableModel is not a MVC model
    Well, you are are right, it is all about interpretation...
    I do have the following (as Max does):

    public void find(Hashtable criteria) throws GUIFatalException{
    logger.info("Search request executed.");
    try {
    // search records in the database
    RecordModel[] records = db.find(criteria);
    // update table model
    tableModel.clear();
    tableModel.setValues(records);
    tableModel.fireTableDataChanged();
    } catch (DatabaseException ioe) {
    logger.log(Level.SEVERE, ioe.getMessage(), ioe);
    throw new GUIFatalException("System problem occured. ", ioe);
    }
    logger.info("Search request completed.");
    }

    Accordong Max: RecordModel[] is the business model and table is just an GUI model. So actually you both almost agree on this part. The differnece is that you would really make a separate class for this DatabaseModel which would have a reference to DB interface, so that Controller access only methods from this DB Interface.
    Example:
    GUIRecord[] records = dataModel.find(criteria);

    Hm, bad sample..., but generally understand what is the difference in your approach.
    So I think before we can go further, you are going to have to decide which version of MVC you wish to use, then we can move forward from there.

    Let's assume first that I want to follow Max design, because it is what I have now.

    Tx,
    Vlad
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11424
        
      85

    Hi Vlad,
    Vlad Let's assume first that I want to follow Max design, because it is what I have now.

    I was afraid you were going to say that ... now I have to switch my brain's mode to that pattern.
    OK - I think we got to the point where you were getting the column length from the RoomTableModel, which meant that you no longer need the getDocumentModel() method in your GUIController.
    As I don't have any logic in Model, but in Controller. It would be probably the controller, who wouch have to map the new server Record class to the RecordModel. Is it Ok?

    Yes. I had originally suggested:
    2) Leave your MVC as it is, and put a comment in your design decisions document stating that you are using your own Value-Object class (oooh, another pattern in use ) to pass data around, and if the back end database changes then the model can hide that change as I mentioned above.
    However that only applies to the MVC where the model abstracts the connection to the database. It does not apply to the MVC where the Controller connects to the database.
    So rewrite that suggestion:
    2) Leave your MVC as it is, and put a comment in your design decisions document stating that you are using your own Value-Object class (oooh, another pattern in use ) to pass data around, and if the back end database changes then the controller can hide that change since it handles the creation of the TableModel which is all the View gets to see.
    Woohoo - it now fits in perfectly with what you want.
    First suggestion: before we start discussing it, am do I understand you correct, that actually it is not so bad to have #2?

    Number 2 is fine - it is one of the reasons for having MVC in the first place: the abstraction between the database and the view. Either can change without affecting the other.
    Andrew, I am really really sorry for all these stupid questions, but it is thrue: I have no clue about designing GUI clients...

    You seem to be working fine.
    Personally I am not a GUI fan. I have been working in back end systems for far too long, and I find that working in GUIs tends to slow me down. I can develop a reasonabe GUI interface if I have to, but I will never get an award for best design. And a feature of any application I write is that the GUI can be 100% bypassed if desired (and I do desire it)
    Accordong Max: RecordModel[] is the business model and table is just an GUI model. So actually you both almost agree on this part. The differnece is that you would really make a separate class for this DatabaseModel which would have a reference to DB interface, so that Controller access only methods from this DB Interface.

    Correct.
    Regards, Andrew
    [ October 06, 2003: Message edited by: Andrew Monkhouse ]
    Vlad Rabkin
    Ranch Hand

    Joined: Jul 07, 2003
    Posts: 555
    Hi Andrew,


    1) My view is then not connected to the Model directly (I don'r want to use "hook" methods" and own-defined Listener). May I do it or I do have to create a Listener to let Model change View accordinately?
    2) My controller still has reference to the TableModel. If call book method, I do want to referesh only one row in the table, but not replace the whole table.
    2) My Table doesn't need than to provide thes method: public int getColumnLength(String name);
    It will be provided by Controller, since GUIBookComponent and GUISerchComponent need this method, not a JTable
    and Contoller will use getSchemaModel() method accordinately to extraxt length of the field.
    3) Where should put this block then:

    should I leave it in controller? Shoud id go to the view?
    4) If I have now a separate Model, I don't need actually an adapter on the server. I can leave then
    the method (e.g.) int find(String[] criteria) as it is, but my Model will provide then method:
    RecordModel[] find (Hashtable criteria). (RecordModel class will be then in client package, which solves the problem discussed earlier.


    Could you comment my statements?

    Tx,
    Vlad
    [ October 06, 2003: Message edited by: Vlad Rabkin ]
    [ October 06, 2003: Message edited by: Vlad Rabkin ]
    [ October 06, 2003: Message edited by: Vlad Rabkin ]
    Vlad Rabkin
    Ranch Hand

    Joined: Jul 07, 2003
    Posts: 555
    Hi Andrew,
    one more question: if I make a separate class Model, mai contain GUI client specific information? If yes, could make parsing of db record to gui record there:

    Tx,
    Vlad
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11424
        
      85

    Hi Vlad,
    1) My view is then not connected to the Model directly (I don'r want to use "hook" methods" and own-defined Listener). May I do it or I do have to create a Listener to let Model change View accordinately?

    You don't have to use the hook methods. They are a nice feature in the MVC that Eugene described, but they are not required.
    3) Where should put this block then:

    should I leave it in controller? Shoud id go to the view?

    It sounds like this can and should be in your controller.
    4) If I have now a separate Model, I don't need actually an adapter on the server. I can leave then
    the method (e.g.) int find(String[] criteria) as it is, but my Model will provide then method:
    RecordModel[] find (Hashtable criteria). (RecordModel class will be then in client package, which solves the problem discussed earlier.

    Hmmm - not sure what you are getting at here. Do you now have a separate model (I thought you were going with Max's MVC), or are you building this into your table model? If this is in your table model, then who is the consumer of the RecordModel class?
    if I make a separate class Model, mai contain GUI client specific information?

    Normally it could contain information and methods that will be used by the GUI(s) but it will not contain GUI components or methods itself.
    As I mentioned before, one of the reasons for MVC is to abstract the view from the database access. If you combine the database access and view specific information then you loose that advantage.
    So your model could contain methods to validate fields, return field sizes, do various calculations. But your model would not normally contain buttons or AWT event listeners.
    Regards, Andrew
    Vlad Rabkin
    Ranch Hand

    Joined: Jul 07, 2003
    Posts: 555
    Hi Andrew,
    Hmmm - not sure what you are getting at here. Do you now have a separate model (I thought you were going with Max's MVC), or are you building this into your table model? If this is in your table model, then who is the consumer of the RecordModel class?

    Sorry!
    I don't know what happened, but my text before the pic with classes is away.
    I wrote you there, that after reading comments for MVC from Sun, I think that you are right: TableModel is not a model in MVC and controller shouldn't have any logic (My controller has pretty complex logic : it invokes lock-read-update-unlock on the server). So, I decided to ask you, what you were afraid of .
    That is why I came up with the idea that no adapter is needed, because Model on the clinet can play the role of adapter. Of course I came up then with idea of the class desrcibed above:
    RecordModel will become a suncirtfy.client class (not suncertify.db). It will be used exclusively on the client. The Database interface will have then (as defined by Sun) String[]. All the parsing will be performed than in Model class, because Model class will be aware of GUISchema(View) and and SchemaModel(Database).
    If I correctly understood your last mail it is Ok for the model to contain GUISchema (since it is not one of the swing classes).
    You mentioned above in one of your first mails that View could directly invoke get methods for field info from the model. Since you say that "hook" method is not a requirement in MVC, I don't see any reason for the view to have a reference to the model. It can get the field info though the controller.
    You said the updating TableModel in contoller is Ok. Why? It contractics to your statement that TableModel is actually the part of view?

    Andrew, I guess some of my questions are asked twice, but I do to make sure I didn't miss something in understanding of what you are saying.
    Tx,
    Vlad
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11424
        
      85

    Hi Vlad,

    You mentioned above in one of your first mails that View could directly invoke get methods for field info from the model. Since you say that "hook" method is not a requirement in MVC, I don't see any reason for the view to have a reference to the model. It can get the field info though the controller.

    I think that was when I was talking about the following design:

    In that design, the model can push updates to the view(s) that are connected, and the view(s) that are connected can get static data (such as the schema) from the model at any time. It just saves the step of going via the controller.

    You said the updating TableModel in contoller is Ok. Why? It contractics to your statement that TableModel is actually the part of view?

    That was when I was talking about Max's design:

    In which case if the controller is pushing the TableModel to the View (and keeping a reference to the Tablemodel itself) then it can update the TableModel directly.
    Regards, Andrew
    Vlad Rabkin
    Ranch Hand

    Joined: Jul 07, 2003
    Posts: 555
    Hi Andrew,
    sorry, sorry again for this confusion.
    I talk now only and only about the design presented by you (picture 1), not Max one.
    TableModel is the part of view. Model is a model in MVC.
    In that design, the model can push updates to the view(s) that are connected, and the view(s) that are connected can get static data (such as the schema) from the model at any time. It just saves the step of going via the controller.

    The most important word hier is "model can push updates to the view(s)".
    There are two ways to do it:
    1) Listeners
    2) view calls a method from Controller, and controller calles a method in Model. (You said it still Ok).
    In the second case My view doesn't need a reference to the Model and a model doesn't need a reference to the view. Table is considered then also as a part of view.
    1) It also means that update of TableModel should be done inside View, not in Controller. Am I right?
    2) I don't need an adapter on the server (and therefore db.RecordModel wrapping String[] and SchemaModel.) All this can be done there by client.RecordModel and the parsing of client record abstraction (RecordModel) and servers one (int recNo, String[]) will be performed in Model. Am I right?
    Tx Andrew,
    Vlad
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11424
        
      85

    Hi Vlad,
    update of TableModel should be done inside View, not in Controller. Am I right?

    Correct.
    I don't need an adapter on the server. All this can be [...] performed in Model. Am I right?

    Correct.
    Regards, Andrew
    Vlad Rabkin
    Ranch Hand

    Joined: Jul 07, 2003
    Posts: 555
    Hi Andrew,

    Finally, I understand all this staff. 6 mails from you helped me to figure out what I failed to understand by reading many books and articles!
    Tx!!!
    Vlad
    P.S. Don't you want to compete with Max and write your own book?
    [ October 07, 2003: Message edited by: Vlad Rabkin ]
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11424
        
      85

    Hi Vlad,
    P.S. Don't you want to compete with Max and write your own book?

    My own SCJD book? No way - I have serious doubts about anyone competing against Max's book. His is just too good.
    But writing a book in another area ....
    Regards, Andrew
    Vlad Rabkin
    Ranch Hand

    Joined: Jul 07, 2003
    Posts: 555
    Hi Andrew,
    But writing a book in another area ....

    Well, I know that you are not fan of GUI, but that one of the things ewhich you can perfectly do. What about book about MVC?
    Andrew, I hope I have the last question about it ....
    I have changed my GUIclient completely to follow the concept that TableModel is a part of view and is not a MVC model.
    I also through away adapter on the server. I have only extended original Sun interface to by adding getSchemaModel.
    I put the interface SchemaModel in suncertify.util package (only classes implementing it are in suncertify.db package) to avoid blaiming me in using classes from db package. Instead of requestion controller or model for any Schema info, I get the cwhole object once and keep a reference to it in the view.
    I don't use neither "hook methods" neither Listeners to update view if the Model changes its state. I use straight and simple invocations sequence View->Contoller->Model. So, NO ONE, except contoller has reference to the model.
    I don't want to annoy you by asking it 3-rd time, but I have to
    Is it Ok?
    All books and you also say that all Views register themself within the Model, to get notified if the model state changes. It means for me Listener interface is a "MUST" and contoller and model instead of returning a value just fire events on all registered view Listeners.
    As you see it is not a case in my design. Only the view, which invoked method in the contoller gets/puts and gets needed info from/to the model. All my components are represented now a one view, but if had other view, no one would be notified if the Model changes.
    Advantage: simplicity and no any dependence of the view from the model.
    Disadvantage: Am I breaching MVC design or not???
    I've seen that you described the design as possible, but still
    1) Is it Valid MVC design?
    2) May be I shouldn't risk and build-in event notifiying logic from Model to View?



    Sample of my MVC:

    Many Tx,
    Vlad
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11424
        
      85

    Hi Vlad,
    The advantage to the model being able to push data to the clients is that updates can happen automatically. If there were two views dependant on the model, then both would get updated whenever the data being modelled changed.
    For example, if you decided to have one view which displayed only available records, and another view that displayed both available and booked records, they could both be working off the same result set. Whenever either view changes the search criteria, both views would get updated.
    Since you are not having the model push updates out, each view would have to manually get an update from time to time. If only one can be viewed at any given time, then you can do the update whenever the view gets focus, but if the user want's to be able to view both sets simultaneously, then there is always the chance that one of the views may be displaying old data.
    As long as you have made a conscious decision that you don't believe that the added complexity is required, and you document that decision, then you should be OK.
    You might want to look at how little is required to implement a model that can push updates to views though - I would estimate that it would take about 10 lines of code from where you are now to get this working.
    Regards, Andrew
    Vlad Rabkin
    Ranch Hand

    Joined: Jul 07, 2003
    Posts: 555
    Hi Andrew,
    You might want to look at how little is required to implement a model that can push updates to views though

    Agreed. I have made it today. The only think what I don't do is hoock methods. So, my architecture suits the design described by you.
    Thank you so much!
    Best,
    Vlad
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: GUIContoller