Originally posted by Chee-Chan Keng:
My GUI requirement states that:
"It must allow user to book a selected record, updating the database file accordingly"
But it did not mention "unreserve" the record, does that mean we just let the user book but cannot un-book the hotel?
If you want to allow the user to unbook, its OK. Some allows to unbook, some don't. Whatever you assume you need to document though and provide the implementation accordingly.
Also, in the interface, I have the following methods, are my assumptions correct and meet the requirements:
public String read(...) - no GUI implementation
public void update(...) - associate GUI with "book" button, can this be translated to updating the "owner" field with customer name?
Yes, you can re-use the given update method to book the record instead of providing another one.
which implies that the user can only modify the "owner" field in the record? or all fields in the record?
We have to implement update method such that it MUST be able to update all the records. Note that this functionality is not used at GUI though. We can use the same update method to book as said before.
public void delete(...) - no GUI implementation
public int find(...) - associate GUI with "search" button, assume hotel with empty "owner" is available.
This method can be used as part of search functionality. But if you take another look at the find method and the GUI search requirements, we need to have another find method that does exact search. This method, as per my instructions does "startsWith" search. But GUI search needs exact search.
public int create(...) - no GUI implementation
public long lock(...) - no GUI implementation, but used when other methods are called.
Yes and No. It depends on your locking mechanism. Some people provide client side locking capabilites. Then you must provide this in GUI.
public lon unlock(...) - no GUI implementation, but used when other methods are called.
Same as above.
If lock() is called and JVM crashes, we assume all records are lock free when we restart the application, right?
I would say yes. Locks are not persisted, so they live as long as JVM is up. Once it crashes application losts knowledge of all non-persistent objects including locks in the application.
I see other people are using complicated methods to generate the cookie, if I just use an int and increment the value from my server, my cookie should be unique enough, why do they need to use Math.random() or other techniques to generate the number?
You can use a number for cookie as long as you are sure it is unique.
thanks a lot!!!
[ March 08, 2004: Message edited by: Chee-Chan Keng ]
Originally posted by Gaz Smith:
3. An incremental integer. As suggested above. The two obvious drawbacks seem to be, that it offers no security since the cookie can easily be guessed (although is security in anyway a requirement?) and two the counter will eventually wrap and cause you problems.
I prefer the idea of 3 since it wouldn;t be hard to justify the lack of security in this spec. I was thinking however of using a stack instead of a simple incremental counter. This way cookies are returned once they're finished with and it's unlikely you'll run out of cookies this way (c.f. counter wrap).
Originally posted by Gaz Smith:
I've been lurking for a while but simply haven't needed to post since I've been able to find sufficient detail from past posts!