Challenge:

Constraints.

Criteria:

• Build a frame containing:
  • A combobox with the two options; “one-way flight” & “return flight”.
  • 2 textfields representing the start & return date
  • A button for submitting the selected flight.
• The return textfield is enabled if the combobox’s value is “return flight”.
• When the combobox has the value “return flight” & the return textfield’s date is strictly before start textfield’s then the submit button is disabled.
• When a non-disabled textfield has an ill-formatted date then it is colored red & the submit button is disabled.
• When clicking the submit button a message is displayed informing the user of their selection (e.g. “You have booked a one-way flight on 04.04.2014.”).
• Initially:
  • The combobox has the value “one-way flight”.
  • Both textfields have the same (arbitrary) date (it is implied that the return textfield is disabled).

The focus of Flight Booker lies on modelling constraints between widgets on the one hand & modelling constraints within a widget on the other hand. Such constraints are very common in everyday interactions with GUI applications. A good solution for Flight Booker will make the constraints clear, succinct & explicit in the source code & not hidden behind a lot of scaffolding.

Flight Booker is directly inspired by the Flight Booking Java example in Sodium with the simplification of using textfields for date input instead of specialized date picking widgets as the focus of Flight Booker is not on specialized/custom widgets.