NX:Bodgit and Scarper

[ulvi ugur]

Hi all,
Just downloaded the assignment and had a look at it. My first question is more about the use cases. It says "It must allow the user to book a selected record, updating the database file accordingly".
Now, what does this really mean ? A customer (or CSR) is starting the client, using the search mask finds some records which matches his criteria and if he selects this record from the results table, this contractor is "reserved" for him. Until now, all is fine, but how come the server interface has update, delete, create, lock, unlock, etc. methods ? Does this mean the client should have the ability to do all this as well ? (this is not mentioned in GUI functionality). That is weird also since we allow the regular customer to add records in the DB.
Another simple question about porting the solution to internet, do you think we are talking about using the application as an applet and running the server on the originating server ? Or is there any other plan behind this idea ?
I guess I will be here for a while.

[Mike Southgate]

when you book a record you need to update it. There is no explicit requirement for deleting or creating records other than having to implement the methods. lock and unlock are required to handle two clients trying to update the same record simultaneously.
ms
[ August 05, 2003: Message edited by: Mike Southgate ]

[ulvi ugur]

Hi,
I guess I was not clear enough, my bad. I understand that locking records/synchronization are all a big issue. What I was asking briefly :
1) What I understand from spec is use swing/create a search mask/book the selected record and that's it. Whereas the server interface is specified to be doing more, so are there more than one client GUI ?
2) How should future plans of usage over internet should affect the design ?
Thanx 4 your time.

[Mark Spritzler]

Ulvi, there is only that one GUI. As far as the methods you discussed, the only ones you won't use in your assignment are create and delete. You will have to implement them in your Data class. However, you will use the update, lock and unlock methods. When you book you will have to call the update method to update the data file. And in server mode you will use all three in your booking.
Question #2, what does the internet have to do with the assignment. Is there any mention of it in your instructions? I wouldn't consider it.
Mark

[ulvi ugur]

Originally posted by Mark Spritzler:
Ulvi, there is only that one GUI. As far as the methods you discussed, the only ones you won't use in your assignment are create and delete. You will have to implement them in your Data class. However, you will use the update, lock and unlock methods. When you book you will have to call the update method to update the data file. And in server mode you will use all three in your booking.
Question #2, what does the internet have to do with the assignment. Is there any mention of it in your instructions? I wouldn't consider it.
Mark

I got the first point.
About the second one, my assignment says "In the future, Bodgitt and Scarper wants to move into Internet-based marketing and hopes to provide their services directly to customers over the Web". If they ask me I would say, use the application as an applet over the Web and that's it. I'm only wondering if one could design better keeping internet in mind. Shall I ignore it ?
Thanx for being there.

[Jim Yingst]

I'm only wondering if one could design better keeping internet in mind. Shall I ignore it ?
Don't ignore it. It's something you should consider at least, but remember it's not something you have to actually do. Try to design your other classes so that if someone did want to make an internet client, they could re-use many/most of your classes. As much as is reasonably possible anyway. For example if they decide to run a servlet for web access to the DB, none of the client code that uses swing or awt classes will be useful - it must be replaced. But hopefully other parts may still be useful. Using MVC architecture for the client will help here - keep asking yourself "if I had to replace this with a servlet, or applet, which parts would change?" This may help guide you to group the changable parts separately from the unchanging parts, which will probably be a better, more flexible design than otherwise.

[Mark Spritzler]

Ah, that was my question of whether it was in your instructions.html
What I really think the point of this instructions it to keep your GUI display decoupled from the "business logic" such that you can replace what the display looks like without having to "Gut" out the business logic and/or database aspects of the application.
Mark

[ulvi ugur]

Thx guys, I got the initial push. Will come back 2 u about other issues.