Horst Dehmer

Hi Phil, hi Amardeep!
Thanx a lot for your input!
First of all I think that a clear design also has to be quite easy to understand (Phils reasoning). Even if there are some more interfaces/classes a rookie would have dismissed. Second: I won't write crappy software on purpose if some IT manager states "Sooner or later we kick it anyway!" So I'd say I'm looking for the hard way
Eventually it all comes down when you're justifing your approach (and list the alternatives).
What counts: For my first shot I AM a 3-tier supporter:
Database service and business service will go to the RMI registry (or local), lock/unlock will be hidden from the business layer (sorry Amardeep). I don't want to run into threading issues. As I understand the specs, RMI does not guarantee handling two or more calls of one client with the same thread. How could that go anyway, if a thread has to wait. I'm going to use a mutex implementation of an abstract semaphore interface. The mutex enforces real strict locking: Only the owner (thread) of a mutex can unlock it. Think cookies won't be really necessary in that case. Maybe I change the locking in favor of cookies. Considering that I even might change to a 2-tier architecture
O.k. it time to code If I run into trouble you will know, when everything's going fine, I let you know, too.
Thank you very much again for your input.
Horst.
PS: The mere asking and considering in this forum with all you guys, gets my thoughts sorted out.

Hi guys!
Doing J2EE for years I'm a potential 3-tier man
For me that means having remote and local access to a database service and a business service. To hide the RemoteExceptions in local mode, I'm planning to use business delegate layers between database and business service and business service and (thin) client. I consider this as the cleanest design. Locking would be done solely in the database service.
What worries me is that this approach might not be readily understood by a junior programmer at the first and maybe at the second look. I think it'll be too much interfaces and factories/service locators for this "simple" assignment, which is meant as a kind of proof-of-concept anyway (-- The IT director does not anticipate much reuse of the first Java technology system...)
So what you 2-tier/3-tier guys think?
PS: The business service would be really thin and maybe not worth the trouble

Horst

Hi David!
Considering that DB/Data stand for arbitary database files, assuming/defining a implicit primary key which suits the needs for the assignment would be wrong in my opinion.
Considering further that DB has no mechanism to define/handle primary key meta data, I'd suggest that the DuplicateKeyException is just reserved for later use. It might only part of the methods signature because client code may be adopted smoother if such functionality is some day provided by DB.
What ya thinkin?
Regards, Horst.

Hi Cathy,
like Siddharth I added some method to the Data class (mostly criteriaFind related). I feel comfortable with this. But I think you should remember that Data is not responsible for one special database like fbn. I'd say searching carriers in Data is too close to business logic and therefore Data's not the appropriate place to put it. I'd rather have a method which does something like SELECT DISTINCT on any field. From the client you can call this on the carrier field.
Hope this helps, Horst.

Hi all,
think I did mention it a few days ago...
ANY is a valid three letter code for an airport:
ANY - Anthony, KS [Anthony Municipal Airport], USA
Don't quite like the idea of dropping this issue.
So what's it supposed to mean if the user types 'any' for origin/destination airport? I decided to provide some sort of lookup (9200+ airports) with a 'don't care' entry. ANY-criterions won't be included in the criteria and thus won't come thru to my criteriaFind() method.
Whatya think? Horst!

Hi Sid,
Try to use setBounds(Rectangle) from JDialog.
Horst.

Hi all,
actually there are about 9297! tree letter codes for the (important) airports around the globe.
AAAAnaa, French Polynesia
AABArrabury, Queensland, Australia
AACAl Arish, Egypt
AAEAnnaba [El Mellah], Algeria
AAFApalachicola, FL [Apalachicola Municipal Airport], USA
...
to
ZXARota [Rota Naval Station], Spain
ZXDSan Isidro, Dominican Republic
ZXESculthorpe, United Kingdom
ZYLSylhet [Osmany/Shylet], Bangladesh
ZZUMzuzu, Malawi
ZZVZanesville, OH [Zanesville Municipal Airport], USA
The funniest thing is that ANY also is a vaild airport 3lc:
ANYAnthony, KS [Anthony Municipal Airport], USA
What about that? My idea was to provide a text field (for power users) and a lookup button for ordinary users. Think the 'any' thing I'll handle with a check box (enable/disable) criterion.
Cheers, Horst!
PS. I'd benefit from that lookup thingy too, cuz my girl friend's a flight attendant and I often have to lookup where she's staying.

Hi Bal, hi Burk!
Many thanx for your replies! I like something from each of your inputs: I like to take baby steps persuing a goal and I like to model before coding.
Think the questions which bother me most are
1. Should I have some global accessible controller instance on which upon depend (too) many classes or
2. should I rather register my table/table model with a controller
Maybe you could give me a more concret insight in your designs
Thanx again, Horst.

Hi there, I'am a new kid on the block :-)
I got some problems in designing my client app. I know something about MVC, JFC and even business logic. But I just can't get it together :-(
My thoughts so far:

have something that handels the business logic (like you know searching flights, booking seats, etc.)

send some events (button/menu hits) to a central contoller instance (maybe a Singleton)

let the table model get its data from somewhere

keep coupling low and

keep it (nice and) simple

But how to get all of this to work together smoothly. I mean which part has to know/create the other parts? Do I have to have one Controller which knows everything? How am I gonna direct the data to the data aware components?
I'd appreciate any hint or suggestion. I hate this UI stuff.
Cheers, Horst!