• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Somehow totally lost :)

 
Baruch Sadogursky
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi guys.
It might be the stupidest post here. If it is - give me an award
I have purchased the Bodgitt and Scarper assignment many months ago, have read the requirements, and said to my self � well, I can�t quite understand where to start. Well, I�ll open new thread in mind, I�ll read a lot JavaRanch, I�ll buy Mehran�s book, and eventually, things will be clearer to me.
Meanwhile I did the SCWCD, SCBCD and the SCMAD, time passed, deadline came closer, but I still don�t know where to start
Any medicines to solve the hard case?
 
Jacques Bosch
Ranch Hand
Posts: 319
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, for me the easiest place to start was to implement my Data class. At least when you've done that, you can access the data properly. It's also the basis of the whole project. I then designed and wrote my client GUI. And then I wrote everything between the two.
Don't know if that helps any.
J
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree. Focus on writing a low level API-type class that will access the Data class. It should offer add, remove, and modify. Build from there.
All best,
M
 
Baruch Sadogursky
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
10x.
Do it now, and feel much better
 
Barry Gaunt
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Got the same problem, but it's mainly laziness and always finding easier things to do. Maybe you will still get done before me...
 
Baruch Sadogursky
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Barry, at least you have the courge to admit
Let's bet, maybe it will stimulate our both
 
Min Huang
Ranch Hand
Posts: 100
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree. Start by writing the Data class. Go grab yourself a copy of eclipse:
http://www.eclipse.org/
Learn how to use JUnit:
http://www.junit.org/index.htm
And then start hammering away at the Data class. Then figure out if you want a fat client or a thin client. Where's your business logic gonna go? That is, say something like read, update, lock, unlock: that's database logic. Does your client need to know that? Or does your client only need to know search/book?
Once you figure that out, start doing the GUI and you'll know what kind of interface your GUI is going to be holding (either a DB interface, or a different interface for the fat client).
Once you're done with the GUI you are on the home stretch. Use RMI or sockets to add that networking layer by writing a socket client that implements that interface we talked about in the last paragraph. Let your controller pick to instantiate a socket client or a Data object depending on stand alone or client mode and BAM! you are just about done. Whewww!!!
 
Baruch Sadogursky
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Min Huang:
Whewww!!!

Min, Whewww indeed
Thanks a lot! The issue of a thin/fat client is a good dilema indeed. I think that Sun, with all their "Network is the computer" thing will love a thin one
 
Min Huang
Ranch Hand
Posts: 100
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Min, Whewww indeed
Thanks a lot! The issue of a thin/fat client is a good dilema indeed. I think that Sun, with all their "Network is the computer" thing will love a thin one

Hey Baruch, be careful about this - look at your exam carefully. Some exams have lock/unlock return/take a lock cookie. If that is the case, there is a strong suggestion that the client should take part in the locking process and know about the database logic. Whether the client actually does or not is up to you. I suggest you search the forums for fat/thin client discussions, but be prepared cos its a doozy reading through them all!
As for me, my project's lock/unlock method did indeed require the use of lock cookies. I assumed that because of this method signature, that the client should take part in locking/unlocking. I don't know why, but maybe URLyBird had a good reason for doing that? I decided not to step on anybody's toes and do what I believe they expected.
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Min and Baruch,
I remember to have been a little ( ) involved in that huge discussion about tiers. Published scores have proven that both designs are equally accepted by SUN for the current assignments.
But Min, what makes you suggest that versions with lock cookies require a fat client design (DBAccess interface exposed to the client)?
Regards,
Phil.
 
Baruch Sadogursky
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I do have the cookie staff in lock() / unlock() methods of the DB interface. That makes the client fater, you are totally right, but I assume by their name ("cookies"), that they are similar to HTTP cookies, and regular browser is still considered a "thin" client, isn't it?
What I mean is - the client could have presentation logic only, but with the capability to identify itself, which I suppose the meaning of this "cookie" staff. Am I missing something?
[ April 12, 2004: Message edited by: Baruch Sadogursky ]
 
Min Huang
Ranch Hand
Posts: 100
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But Min, what makes you suggest that versions with lock cookies require a fat client design (DBAccess interface exposed to the client)?

Hey Philippe. Yes. I remember the discussion that you took part of (that was the doozy ). My rationale was that the customer makes a big stink about Data.java having to implement DB interface exactly, so he must want that for a reason. Given that the lock/unlock methods have lock cookies, the information seems to point that exposing this interface to the client is the reason. Whether or not that is the real reason I cannot say, but in my design document, I note this as my assumption.

What I mean is - the client could have presentation logic only, but with the capability to identify itself, which I suppose the meaning of this "cookie" staff. Am I missing something?

Sounds like a plan! I don't see what's wrong with that approach either.
 
Baruch Sadogursky
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Guys, could you please drop a link to the notorious discussion? I think it is the right time for me to read it
 
Satish Avadhanam
Ranch Hand
Posts: 697
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Baruch Sadogursky:
Guys, could you please drop a link to the notorious discussion? I think it is the right time for me to read it

Here it is Should lock methods be callable by the client
I guess they are talking about this link only.
Good Luck.
[ April 12, 2004: Message edited by: Satish Avadhanam ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic