aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX: two questions concerning the client GUI 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 "NX: two questions concerning the client GUI" Watch "NX: two questions concerning the client GUI" New topic
Author

NX: two questions concerning the client GUI

Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi everyone,
I have some two questions concerning the GUI:
1. Do you think it's necessary to have keystroke mnemonics and tool tips?.
2. At my View when I call the book-method of my Controller-Class, I get the field values of the concerning record not from the table itself but from the tableModel. Do you think that's ok?
I do that for two reasons:
a. In my tableModel, each Record contains also a Record number, but in my table, the record column is removed.
b. the order of the columns at my table can be changed. But my book-button is only enabled if the boolean available field is true. Thus, if the availability column as been moved, the verification of its value can lead to an error.
To justify my decision to extract the values from the tableModel, I can list two points:
I. All events within my GUI occur in the event-dispatching thread. Thus, my table mirrors the values of the actual tableModel.
II. The rows of my table can't be moved, thus I don't have to be afraid that the selected row doesn't refer to the concerning values in my table model.
Is that reasonnable?

Thanx & Regards
Ulrich
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
Hi Ulrich,
1. I had both keystroke mnemonics and tool tips, but I don't think either is necessary. In my opinion they are unlikely to contribute to a higher GUI score.
2. If you do it this way, how are you preventing booking a stale record (that is, a record that has been updated in the database by another client, but is not currently up-to-date in the booking client's view)?
2a. Why not include the record number in the JTable? I found it useful when I was testing the GUI since it uniquely identifies a record in the database. If you don't display the record number in the JTable, then maybe you shouldn't have the record number in the tableModel either. It makes sense to me for the tableModel to exactly match the contents of the JTable.
2b. I don't think this is a problem. You know the column index of each column in the tableModel. The fact that a user rearranges the columns in the GUI's JTable, shouldn't change the column indexes known in the tableModel. This is a conversion that the JTable takes care of itself. Check out the appropriate Java API sections on JTable and TableModel, but I believe this is true.
I. Is it enough that your JTable is consistent with your tableModel? When you book a selected record don't you want your selected record to be consistent with the database itself? Otherwise, aren't you giving the user the opportunity to book a stale record (one that another client may have already booked)?
II. I think that's true but I'm not sure how that justifies the decision to maintain record consistency with the tableModel rather than the database table itself.
Hope this helps,
George
[ February 02, 2004: Message edited by: George Marinkovich ]

Regards, George
SCJP, SCJD, SCWCD, SCBCD
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11509
    
  95

Hi Ulrich & George,
Regarding the tooltips and keystroke mnemonics - I think that one of the things that will contribute to a good score is having an easy to use interface. In some respects this means giving the users what they expect from every other application that they currently use. So currently users are used to having tooltips, mnemonics, keystroke equivelents (So Ctrl-X or Ctrl-Del for "Cut"), and tool bars. It doesnt matter if they are overkill for this assignment - they are what the user currently expects to see in every application they get.
Regards, Andrew


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

Joined: Oct 27, 2003
Posts: 90
I think that it's alright if your model doesn't reflect exactly the data in the view (in terms of amount of data it displays). After all, it is the responsibility of the data model to process the "raw" data, which may include choosing to ignore some of it!
In addition, you could envisage a different view being registered with the model that may be interested in data that isn't currently displayed in the view.
So I think your approach is fine. (Sorry George - don't mean to deliberatly contract you as your posts are always informative!)
As for keyboard accelerators, I think like Andrew, that it'd be a shame to get marks deducted for something that's so easy to add!
Regards, Steve


SCJP 1.4, SCJD, SCWCD 1.4
Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi George, Andrew, Stephen,
Thank you for your answer.
Concerning point 1:
Andrew, Stephen, you convinced me, I will implement it.
George,
thanks for you informative comments. I will reply to your objections, helping me to clarify my own position.

2. If you do it this way, how are you preventing booking a stale record (that is, a record that has been updated in the database by another client, but is not currently up-to-date in the booking client's view)?
I. Is it enough that your JTable is consistent with your tableModel? When you book a selected record don't you want your selected record to be consistent with the database itself? Otherwise, aren't you giving the user the opportunity to book a stale record (one that another client may have already booked)?

Good point. In my book-method of my RoomAdapter-Class I make a validation after locking the concerning record:
lock - read - validate - update - unlock

2a. Why not include the record number in the JTable? I found it useful when I was testing the GUI since it uniquely identifies a record in the database. If you don't display the record number in the JTable, then maybe you shouldn't have the record number in the tableModel either. It makes sense to me for the tableModel to exactly match the contents of the JTable.

In my tableModel I store the records as objects called RecordModels.
In my RoomAdapter-Class within my find-method I create new Objects with the properties values, recordNumber and boolean availability. Thus for my table I only get the values of my RecordModel, I don't remove anything:
In my tableModel-Class I have two different methods:

Hope that clarify my position.
II. I think that's true but I'm not sure how that justifies the decision to maintain record consistency with the tableModel rather than the database table itself.

You're right. I meant that this is not a justification for the tableModel and against the table but that my choice for the tableModel works as well.
Greetings to you three,
Ulrich
[ February 03, 2004: Message edited by: Ulrich Heeger ]
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
Hi Ulrich,
I don't want to discourage you from doing anything in your GUI that you feel will make it easier for the user. The things you mentioned (keystroke mnemonics and tool tips) require very little work to provide. If you provide a menu bar you might look at adding keystroke accelerators for the menu items (in addition to the mnemonics). You could consider having a Help->About menu item. You could consider adding a tool bar. You could consider having on-line help. In other words, there are lots of things that your GUI could contain and probably all of these things make the GUI easier to use (in some sense at least). You must use your judgement about:
1) what is required (things you must provide or you'll be penalized with a lower GUI score);
2) what is not required but you want to provide anyway (perhaps things that do not require much effort, or things you want to learn how to do regardless of whether you get more GUI points by doing so or not); and finally,
3) things that you decide not to provide (maybe because you think they are outside the scope of the project, or they require a level of effort that makes you concerned about introducing bugs into your application for which you stand to gain almost no benefit in terms of a higher GUI score).
In my opinion, the GUI features you mentioned probably belong in the second category.
My only real concern about the stale records was how they affected a booking operation. Because you do a read after obtaining the lock on a particular record, the problem of updating a stale record is solved.
As for providing a record number in the JTable, it is a matter of preference. If you don't think it should be shown to the user, or if you don't think it will be useful, then you shouldn't provide it. It's certainly not required to be displayed in the JTable.
Hope this helps,
George
Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi George,
thank your for your fast response.
You don't discourage me from anything, I find your deliberation very helpful and informative.
In my opinion, the GUI features you mentioned probably belong in the second category.

I agree with you.
Greetings
Ulrich
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: NX: two questions concerning the client GUI