• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Assumptions about the GUI

 
Ranch Hand
Posts: 171
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am making the assumption that since the instructions did not talk about creating an administrative interface, the only user features we need to implment are lookup and flight booking. This would lead to a further assumption that since the interface is limited to these functions, the new database constructor for "Data" would never be needed in the user interface either. Am I going wrong here? Or is it implicit that since the add record method is implemented in "Data", we need to support that in the GUI?
 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Douglas,
I am also making assumptions that we have to provide viewing and flight booking.
For flight viewing we can search the binary file and show them in the jtable. what about booking.
Do we need to modify the no of seats in db.db file or do we need to keep the booking information in seperate binary file?

 
Douglas Kent
Ranch Hand
Posts: 171
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We need to deduct the number of seats available for that flight by the number of desired seats from the customer input. I would NOT keep that information separate...
 
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Douglas,
Spot on. I think these assumptions are pretty fair. The specs never make mention of the fact that you would need to create a new db. This would also mean that you don't have to provide the constructor to the data class.
In my opinion the GUI is the only part in the entire assignment which would be more or less unusable for future projects. What do you think?
With warm regards
Abhijeet

Originally posted by Douglas Kent:
I am making the assumption that since the instructions did not talk about creating an administrative interface, the only user features we need to implment are lookup and flight booking. This would lead to a further assumption that since the interface is limited to these functions, the new database constructor for "Data" would never be needed in the user interface either. Am I going wrong here? Or is it implicit that since the add record method is implemented in "Data", we need to support that in the GUI?


 
Douglas Kent
Ranch Hand
Posts: 171
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I certainly think it would be usable, provided you design it correctly, and de-couple the GUI from the DB-specific methods used to access our little DB...
 
My first bit of advice is that if you are going to be a mime, you shouldn't talk. Even the tiny ad is nodding:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
    Bookmark Topic Watch Topic
  • New Topic