Ewan Livingstone

Another thing that I think is worth doing is attempting to read all content from the file up front, when the user has selected the file. Wrap a big catch statement around your logic that parses the file; if an exception is thrown while trying to read the file, the file is invalid, and you should present an error to the user and make them choose a different file.

My GUI wasn't polished, because I just came to a point where I just wanted to submit rather than spending more time on it.

Some things I might've lost points for (they don't tell you, so this is guesswork):
1. Not using separate threads for non-trivial actions triggered by button clicks. For instance, where a button click results in an RMI call to the server, this should be in a separate thread, so the GUI remains responsive.
2. Everything was centred. Looked a bit weird. Just a result of me giving up after struggling to make AWT/Swing behave itself...
3. You could argue that having a popup booking/unbooking dialog is actually less maintainable than simply letting the user type in bookings into the JTable directly - the obvious future expansion would be to allow users to change other column values (e.g. change # staff for a particular contractor); having a dialog for bookings sets a precedent whereby each such action requires a dialog.

It wasn't horrific, though... some GUI features I did implement:
1. splash screen (new feature of Java 6; splash screen is loaded before the JVM)
2. Tooltips.
3. Everything could be done from the keyboard.
4. Sensible restrictions on field input as you type - you were prevented from typing anything other than a number in the range 0-65535 in the port field, or something roughly resembling an IP or hostname into the hostname field.

I think it's easy to go overboard with this assignment (I'm guilty of this). The 80% pass mark sounds daunting, but the marking is generally not so harsh. You can afford to drop a few points here and there so long as the requirements are met.

Woo & yay, after initially getting a rather confusing result on the website (384/400, but a grade of F), Sun have confirmed that I've passed.

Max marks on everything except for the GUI, where I got 24/40. Not too fussed about that - it was a bit ugly, but I lost patience after working on this thing for far too long (on and off - mostly off! - since Sept '07).

Happy to answer design questions if anyone has one...

Okay, going to be an ass and bump this thread... just the once, promise.

Anyone got any thoughts on the above post?

Just checked on https://www.certmanager.net/sun_assignment/, and I'm very confused! SCJD is listed, with a score of 384... and a grade of F!

Clicking on the link, it gives a breakdown:

General Considerations (maximum = 100): 100
Documentation (maximum = 70): 70
O-O Design (maximum = 30): 30
GUI (maximum = 40): 24
Locking (maximum = 80): 80
Data store (maximum = 40): 40
Network server (maximum = 40): 40

Anyone ever seen this?! Or does a grade of F mean 'fantastic' rather than 'fail'?

My interface is similar to yours. Probably won't get us any more marks than just implementing some find(String[] criteria, boolean exact) type method, but it's good clean geeky fun and interesting to experiment with...

Check your spec. Mine says:

"The final program must have no dependencies on any libraries other than those of the Java 2 Platform."

If yours says the same, then you can't.

I've implemented this pretty much exactly the way you have. The only difference I can think of is that my equivalent of 'PropertyManager' is more generic - I've called it 'Config', and the public API comments make no reference to the Properties class. To my mind, the backing Properties instance is an implementation detail. My class has some other config-related methods that don't use the Properties instance.

A nice thing about this setup is that your getter/setters can parse the fields and convert them into different types. For instance, if you have a numeric property, your getter/setter for that field can convert to/from int. This approach can be extended as far as Lists.

Okay, so a method in the interface DBMain is defined thus in my spec:

// Creates a new record in the database (possibly reusing a // deleted entry). Inserts the given data, and returns the record // number of the new record. public int create(String [] data) throws DuplicateKeyException;

My issue is this: in what circumstance should DuplicateKeyException be thrown? There is no ID/key argument - the implementation must, therefore, either find a deleted record and overwrite, or expand the DB file by creating a new record at the end. Either way, I don't see any way in which there could ever be any circumstance in which one cannot insert a record because the ID/key already exists.

Am I missing something?

Another explanatory note!

Some people have implemented the search window so that as well as 'contractor name' and 'location' fields, there are radio buttons labelled 'and' and 'or'. With this design, if both name and location criteria are specified, the 'or' radio button corresponds to searching using approach (4).

Okay, to pin down what I'm talking about, some pseudocode:

1. if (record.name == nameCriteria)
2. if (record.location == locationCriteria)
3. if (record.name == nameCriteria && record.location == locationCriteria)
4. if (record.name == nameCriteria || record.location == locationCriteria)

Does that help explain what I mean?

Incidentally, the reason I'm reluctant to implement (4) is just that the way I've designed my database layer means that implementing it would mean quite a lot of code changes. My database logic is a little too clever and abstracted for its own good

From my spec:

"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."

I've seen someone interpret this on this forum as meaning that you must be able to do all the following:

1. Search for records that match a particular name.
2. Search for records that match a particular location.
3. Search for records that match both a name and a location.
4. Search for records that either match a particular name, or a particular location, or both.

It's (4) I've got issues with. I think that 1-3 could be argued to be enough to meet the spec - it's only if you read every "or" as a "||" that (4) seems necessary.

Has anybody not provided 4 and passed the assignment?

B&S, v2.3.2.

I think I'm about 90% done.

Hello all,

Not posted here before, but I'm currently doing the last 10% of my Bodgitt & Scarper assignment implementation. Got a few niggling worries around automatic failure, and I wondered whether anyone (ideally someone who has submitted an assignment and got the result) has got any pointers on these...

1. In my database file, contrary to what the spec says, none of the field values are null-terminated. They're all padded with spaces. That is, where a field is 10 characters wide, a 3 character value such as 'foo' will be represented as 'foo ' ('foo', followed by 7 space characters). According to the spec, it should be 'foo\0\0\0\0\0\0\0\0\0\0' (or 'foo\0' followed by 6 arbitary characters), as \0 is the ASCII NUL character.

I've developed by database file parsing code to the letter of the spec, and as a result, in the above case, my database layer will return 'foo ' (i.e. with the 7 spaces). In turn, as the spec requires that if the user restricts their search by name or location, the match must be exact. So if my assessor types in 'foo' as the name, it won't match 'foo '.

I'm considering having a popup if zero results are found specifying that 'foo' does not match 'foo ' to try to address this, but I'm still somewhat affeared...

2. Sounds trivial, but the spec states that all classes should be javadoc'd - does this include DBMain.java (i.e. the database interface provided in the assignment spec)? I'm worried that if my DBMain.java isn't a copy-paste from my assignment, I might get auto-failed. On the other hand, I can also imagine their auto-fail script failing me if I don't have it javadoc'd.

Finally, not something I'd imagine I'd be autofailed over, but something potentially 'controversial' I've done - just wondering if I'm the first to do this...

DBMain, the database interface provided with the assignment, is just horrible for all sorts of reasons. It also doesn't tally well with the spec, as it offers field matching on a 'starts with' basis, where the spec requires field matching on an 'equals' basis. Because of this, I've opted to make my Data class implement two interfaces: DBMain, and my own database access interface, Table. While all DBMain methods work and have been tested, the application itself interfaces with the class using the Table interface and its methods. Under the bonnet, most of the logic implementing the DBMain and Table methods is the same, so there's little duplication as a result. Thoughts?