Christy Keane

Ranch Hand
+ Follow
since Mar 29, 2005
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Christy Keane

Yep, unlock, delete and update all took lockCookies in their signature.
18 years ago
I've no ideas why I lost points on locking...I'll have to investigate. I think a lot of people got this 44/80 score, so we're all probably making similar mistakes.
18 years ago
Yep, passed it. They got back to me this morning. Happy days. Thanks to everyone in this forum for all the help.
18 years ago
I thought that they would have had to say that it was anaotomatic failure though...I dunno
18 years ago
Maybe, I don't know how though - since the questions were on my project, I can't have got them "wrong". I've sent an email to sun...I'll wait and see what they have to say.
18 years ago

I have a question:

I though that the pass mark was 320...I scored 343 but my grade is F. Am I missing something?

Have I failed?

Grade: F
Score: 343
Comment: This report shows the total 1.4 SCJD points that could have been awarded in each section, and the actual number of points you were awarded. This is provided to give you per-section feedback on your strengths. The maximum possible score is 400; the minimum to pass is 320. General Considerations (maximum = 100): 99 Documentation (maximum = 70): 69 O-O Design (maximum = 30): 20 GUI (maximum = 40): 31 Locking (maximum = 80): 44 Data store (maximum = 40): 40 Network server (maximum = 40): 40

[Andrew: changed title to show passed status ]
[ November 04, 2005: Message edited by: Andrew Monkhouse ]
18 years ago
yep, that's what I think as well - I'm going to leave them in...thanks Kai.
John, thanks for the reply.

Which convention specifically does this violate?

I have a policy where I always make my method parameters final - this prevents me inadvertently changing the value of them within the method.

However, the method signatures in the DBAccess interface provided by sun don't have this modifier:

I implement the DBAccess interface in a class called Data.

If I insert the final modifier in the implementing methods in Data, the compiler does not complain - it is happy that Data is implementing the method defined in the interface:

Am I risking automatic failure by having the final modifier here?

If I leave it out in the Data class, it makes my code inconsistent.
I came up with this (sorta hacky) solution:

I wrote my onwn TableModelListener to listen for a table model update event, and if the user tries to change a cell's contents, I replace it with the original contents.

The user can still copy text from the cell.

18 years ago

I have JTable with a CustomTableModel that extends DefaultTableModel.

The reason I implemented a CustomTableModel was that I didn't want the user to be able to write to individual cells.

Therefore I implemented the isCellEditable() method to always return false.

However here is my problem - I need the user to be able to copy text out of the cells.

As far as I can tell the only way I can do this is to make the cells editable - which violates my read-only requirement.

Is there any way I can satisfy both these requirements?


18 years ago
Ok, I know from doing searches of old posts in this forum that this subject has been discussed in the past, so I apologise in advance if you've been asked your opinions on this already.

However I would like to get the opinions of any new people on the forum, and specifically people doing the Bodgitt and Scarper assignment.

I have considered both approaches, and have decided to go with JTextFields.

The main reason I decided not to use the admittedly more user-friendly JComboBox is that I think to implement it correctly, you would have to set up some sort of Observer - Observable link between the GUI and the DB, and this in my opinion goes beyond the scope of the project.

If you don�t setup this link between the GUI and the DB, the contents of the JComboBox could become stale (an existing record could be deleted, or a new record created by another user).

Another small disadvantage is that, potentially, the DB could become very large � this could lead to JComboBox�s containing massive lists of search criteria.

For these reasons I think using the JComboBox possibly could become a problem as the application grows.

The JTextField on the other hand, while not as user friendly, avoids all these problems.

The downside to the JTextField is that the user can enter search criteria that will yield results from the findByCriteria method in the Data class, but these results would violate the following requirement:

It must allow the user to search the data for all records or for records where the name and/or location fields exactly match values specified by the user.

(For example searching on �Fred� would yield �Fred and Nobby� from findByCriteria, but the GUI spec are such that only a search on �Fred and Nobby� should yield this result.)

Therefore an extra level of checking is introduced to filter out these �bad� results.

Again, this is all a matter of opinion, and so long as you document your reasons for your decisions either approach should be acceptable.

What do all of you think?
thanks for the feedback guys.

I'm just looking for any opinions on whether or not an "about" menu item under "Help" is a good idea?

If so, should it simply be a message dialog, or something more complex?

I'ld appreciate any thoughts/suggestions.


Yes. When the server is started, you specify the database location. When you start the client, you specify the network location of the server. when started in local mode you just need to specify the database location.

The client never specifies the database location, just the IP address of the server.

I think I'm going to agree with Jack Gold here...

the program must allow the user to specify the location of the database, and it must also accept an indication that a local database is to be used

I interpret "location" here as the server the database resides on - I'm not sure the client should actually be able to change the database the server is running.

It's just a matter of interpretation of course, but I think if you document your decision with reasonable supporting arguments, they can't punish you with a deduction as large as the one David got.

This document deliberately leaves some issues unspecified, and some problems unraised. Your ability to think through these issues, in the face of realistically imperfect specifications, and come to a tenable solution is something upon which you are being graded.

I don't think that this interpretation of location is more or less "tenable" then John's - it's quite impossible to know exactly which solution is more correct from the instructions, so it's all down to how you justify your interpretation.

Or maybe I'm just trying to avoid all the extra work of implementing this John's way...

Thoughts anyone?
19 years ago