Does server need GUI?

[Artur Popov]

Hi everyone.

This is my first post here. I spent more than 1 month (working on weekends only) writing a program for SCJD.
But now I have some doubts about my decisions.

First of all: does server need a GUI? My one has pure CLI but the assignment says:

Your programs must not require use of command line property specifications. All configuration must be done via a GUI, and must be persistent between runs of the program. Such configuration information must be stored in a file called suncertify.properties which must be located in the current working directory.

So, what should I do? Create a simple frame with a listbox for messages? And what else can be stored in that file? Should this file be used by both server and client?
In general, what does "Your programs must not require use of command line property specifications" mean in simple English?

And one more offtopic question:

It (GUI) 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.

My GUI implements exactly the same functionality as described in Data.jar, i.e. search using all criterial strings provided with 'AND' condition. Is is wrong?

Thanks.

[Anne Crace]

First off, have you gotten a copy of "SCJD Exam with J2SE5" by Andrew Monkhouse and Terry Camerlengo? If you haven't, I strongly suggest you do. It has a nice idea for a Server GUI. Mine is quite similar. For your second question, not sure if your implementation takes care of the OR condition. I use 2 combo boxes, 1 for Name and 1 for Location. Each has an "any" entry in it. The user can choose a name and location, or either one + "any". "All" has been used by others instead of "Any". Same idea. People who have taken the Text field approach often add 2 check boxes, AND and OR, to handle the search. Hope this helps.

[Artur Popov]

No, I'm afraid I don't have that book (or whatever it is). The only e-book I have is "Complete Java 2 certification" by Heller and Roberts.
Is it worth trying to find, or someone can just tell me a short answer? Or it is not short?

About the second: I've read about this idea here, thanks. So, the search panel should contain these comboboxes for 'Name' and 'Location' and text fields for the rest parameters, right?
It's not hard to implement but this solution is not scalable at all: we should write code that performs something like SELECT DISTINCT to fill the comboboxes. That will work slowly if the database is large. And what if the names or numbers of that fields change? This exam forces us to make things in a wrong way

And one more thing:

It (GUI) must allow the user to book a selected record, updating the database file accordingly.

What doen it mean? Should we provide user only with the functions that allow him/her to edit some certain fields? Or all fields?

[Anne Crace]

Here's a link to the book;
SCJD Exam with J2SE 5
You don't need combo boxes AND text fields. One or the other should be enough.
As far as booking a record, mine writes to the owner field a number that is 8 digits long. You didn't say whether you have UrlyBird or Bodgitt and Scarper. I'm guessing it's UrlyBird from what you have said so far. The Monkhouse book provides an elegant solution for writing fields. It uses a Value Object and reads and rewrites all other fields. The owner field appears to be blank, but it's really 8 ASCII space characters. I found out while doing some testing and String.isEmpty() method returned false. If you haven't done so, find a free Hex editor and deal with reading the database file. I would not worry about SQL queries such as SELECT DISTINCT for this assignment. It is out of the scope of the requirements.

[Artur Popov]

Amazon doesn't work with my country.

I have Bodgitt and Scarper, by the way.

I'm afraid you did not understand my question. Or my English is not good enough.

The question was whether a user should be able to edit any field of a record or just some of them? What does 'booking' mean here?

Ok, I've done it like that: the user selects a record and clicks 'Edit'. The record locks and a dialog frame with 6 (one for each field) textboxes appears. He/she can change any value of any field and then press Ok. Is that approach right?

I don't see any problems with writing fields on the level of DAO, my program reads and writes the whole records only, just like an RDBMS.

[Anne Crace]

Artur Popov wrote:

I'm afraid you did not understand my question. Or my English is not good enough.

The question was whether a user should be able to edit any field of a record or just some of them? What does 'booking' mean here?

Your English is fine. I say only some fields should be edited. Two to be exact. For your project, the contractor field gets written to when you book a contractor. You will have to overwrite the available flag for a delete. So from perspective of your interface, delete and update will require edits, and it's the flag for a delete, most likely first field in your database, and owner/contractor, most likely the last field for update. Oh, and only the owner field will ever get changed from the GUI. You have to implement all the methods of the interface because they are going to test it. So you will be calling "delete" from your driver/tester class. The ISBN # for the book is: 1-59059-516-5. I think that is an international number and can help you get a copy in your country. Good luck

[Artur Popov]

Thanks, I've just found a pdf version of that book. There's no other way to obtain it.

It seems that I've done something completely wrong and cannot understand what to do now.
The DAO interface is implemented right (except lock function which returns -1 in the case of timeout, I'm not sure whether this is allowed), now I'm trying to figure out what should GUI do. The one I have now allow doing anything, so I just have to restrict something.

When the user creates a record - which fields should be initialized?
When the user updates it - which fields should be updated?
When the user deletes it - ok, it's clear

Ok, I agree, too many questions, sorry.

[Anne Crace]

My lock() returns -1 too, (only if it can't get the lock) and I have the same doubt. It returns the cookie if all goes well.
GUI should only search() and book(). It might provide Help feature, mine does this.
To create a record, my test class writes all fields. I overwrite a deleted record if one exists, otherwise I add a new one at the end of the file. I use RandomAccessFile with "rw" as access parameter. I use my HotelRooms value object to help with the reads and writes. Mine is very similar to the one in the book. I did have to write a String padding method to use if no deleted records exist as the fields need to be a certain length. I pad with white space from the end of the text up to the size/length of the field. For example, Hotel Name is 64 characters long. Do read the database chapter in the book. It will show you how to use the value object with the data file.

[Ernesto Elias-Nieland]

Hi Artur,

The assignment is sometimes not very clear about what you should do. This is part of the certification. If the spec is not clear YOU have to decide what to do and document it in your choices file.
I think the people at Sun are not very strict about what you do if you documented it properly and you do everything that's a "must" in the spec.

My program is actually very, very simple and provides no functionality outside the spec. It is not nice at all and in real life nobody would use it. But that's fine because it fulfills all requirements.

So don't be to afraid about doing something "wrong". There is no wrong if you can make it clear why you did it.

I hope this helps a bit.

Regards,
Ernie

[Artur Popov]

Hi Ernie.

Well, you know, I think that if assessors have some tool for testing DAO class and it expects the exact behavior as described by the interface without any 'if it returns -1 then...', then this test will fail.

Right now I'm stuck with synchronizing threads and avoiding deadlocks

And about server GUI: in the assignment I have a requirement for all the configuration to be made via GUI. Even for server, I guess.

Regards,
Artur.

[Andrew Monkhouse]

Artur Popov wrote:Amazon doesn't work with my country.

It is available from Amazon Germany - it even says that it is sold and shipped from Amazon Germany.

When living in Holland I found that Amazon USA and Amazon UK would both ship directly to me without problems.

You can also purchase a PDF directly through the link in my signature, or sign up for Books 24x7, which will give you access to a large number of books, mine included.

Andrew

[Sigrid Kajdan]

Hi,

I'd like to revert to the title of this post as I was just wondering about the same thing. Generally, I'd be interested in whether you prefer the GUI variant from the Monkhouse book or the variant of just having a terminal window running?

And do we really need a shutdown hook? I must admit I don't quite understand what the setDatabaseLocked() in the book does (didn't find it in the book)...

Also, if you chose the option of having a terminal window, do you perhaps have a hint of how to do this ( exiting the GUI mode and running a command in a shell)?

Thanks a lot for any hints
Sigrid

[Paul Balm]

I am 99% finished with my solution (Bodgitt & Scarper) but frankly, this is one of the points that I´m still wondering about as well.

The only requirements I have are that: "All configuration must be done via a GUI, and must be persistent between runs of the program. Such configuration information must be stored in a file called suncertify.properties which must be located in the current working directory. "

That is "a GUI" and not, the server must be configured using a GUI and the clients must be configured using a GUI (which would lead one to assume that they want different GUIs).

My solution is the following. Both the "networked client" and the "local client" share the same GUI and the same configuration frame. This configuration frame allows to set certain properties, which are stored in suncertify.properties in the current dir. The difference is that the local and network client allow setting different properties. So, in my solution, you have to use the local client to set the server listen port.

And the server has a command-line interface only, using the properties file as set by the local client.

Basically, the purpose of the local client in this set-up is configuration of the server. You could say that the server configuration GUI *is* the local client.

I would appreciate your thoughts on if you think this is sufficient.
Thanks!

[Sigrid Kajdan]

Hi,

I am starting a configuration gui for all threemodes (just I display different fields). For the non-server modes, I then exit configuration and start the respective controllers which start the views.
For the server mode, I still am undecided whether to do the same (in that case, it would just be a small gui saying "server running"...) or make the server run in a command line window.
I would prefer the latter but I'm not quite sure how to do it. Perhaps somebody could give me a hint? My starting point is the swing configuration window. Simply starting the server and disposing the view does not work... possibly I'll have to start the server in another thread? (Sorry for asking this stupid question :-;)

Cheers
Sigrid

[Paul Balm]

Hi Sigrid,

I think you´re trying to build a Swing command-line client, which is a contradiction.
The idea of a command line client is that it doesn´t have any GUI (no panels, no frames, no nothing). So if that´s what you want to do, just don´t create any Swing components.
If you implement your server using sockets, it will be waiting for incoming connections in a separate thread, which could be the same one as your main method, or you could start another one. If you implement it using RMI, you bind the server in the registry and the RMI registry will manage the threads for you (check an RMI howto).
Hope this helps.

Paul

[Sigrid Kajdan]

Hi Paul,

I think you´re trying to build a Swing command-line client, which is a contradiction.

Of course you're right...! I really should have thought of that myself

Thanks a lot, now it's clear!

Ciao
Sigrid