• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

GUI schema independent of DB schema?

 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am currently doing the URLyBird assignment, and I wanted to run one of my design choices by you to see what people think.

The specification gives the ordering of the fields as name, location, size, etc. This is also the ordering of fields in the given database file, and it is probably the way most developers order the fields in the GUI.

But consider the Search Panel where you can search on hotel name and/or location. Which of these is going to be first in the user's thought process? If a CSR is taking orders over the phone, I think a question like "What hotels have rooms available in New York?" is going to be more common than a question like "Give me a Marriott anywhere in the US." In other words, location is the primary search criteria, and I believe the location dropdown should go first.

Then there's the ordering of fields in the results table. Again I think it's a bit more intuitive to have location come first. But of course the URLyBird users might have a different opinion, and this could change easily. So basically I think the UI schema should be configurable.

In my code I have it all in one line:



This declares both the mapping and the UI ordering. If new fields are added to the DB schema, and they are supposed to be reflected in the UI, then this is all that needs to be changed. Initially I wanted to make it a property, but the specification says that all properties should be configurable in the GUI and this might look too daunting.

The translation between schemas is managed by my Metadata and BookingRecord classes.

So what do people think? Does this idea make sense?
 
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Why do you have a drop down?

Cannot you just have all the fields on the screen and the user fills in the fields which are relevant to his/her query?

By the way, how do you deal with the max occupency thing? The search interface uses string matching, but does not support query such as "give me all rooms in Dallas having 3 or more max occupency.

Moreover, does your server filter the returned result based on the 48-hour restriction? I think the server should return all matched rooms and only when an update has the customer field not null should check for 48 hours.
What do you all think?

S
 
James J McCabe
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Shlomo:

I think it is easier on the user to present a dropdown with the allowed options for hotel and location. You might get away with text fields I suppose.

(The one danger with my solution is that there might be thousands of hotels.)

As for searching on maximum occupancy, it is not part of my requirements. All I have is:

"It must allow the user to search the data for all records, or for records where the name and/or location fields exactly match values specified by the user."

Lastly, my server does not filter on the 48-hours restriction unless the client requests it using a checkbox. (Booking however is always date-validated.)
 
reply
    Bookmark Topic Watch Topic
  • New Topic