Doing Lookups (Notes)

It's a catalog--we look things up in it.

Lookup Data Types

• Vehicle Data
  • Parts, labor, and service lookups are vehicle specific.
  • getCode() is for the lookup engine.
  • getName() is for the user to read.
  • Vehicle object is composed of other data objects.
  • Some Models are "trucks" and use the Make's "truck code".
  • Specific conditions are really just Questions, each with one or more Answers which may be answered, or not.
  • Vehicle accumulates Questions as lookups proceed.
  • In order to know whether a List "contains" an item, we need to implement equals().
  • Whenever we implement equals(), we must implement hashCode() too.
  • Subsequent lookups may use the same Vehicle but have more Questions, or more Questions answered.
  • Because these objects are mutable we need to make copies rather than sharing them freely.
  
  
• Category Data
  
  • Description is used both for input and output.
  • We implement equals() and hashCode().
  • Description implements the RedLine interface.
  • We call this refactoring "Extract Superclass".
  
  
• Immutable Data
  
  • The concept of immutability is so important it has its own Design Pattern but it's really more fundamental than that.
  • Other Java types that are immutable include String and Integer.
  
  

Dialog and Toolbars

• Parallel Interfaces
  
  • We choose a Year and refresh the Make list,
    choose a Make and refresh the Model list,
    choose a Model and refresh the Engine list,
    and finally choose an Engine.
  • We make a trip to the server each time.
  • On clicking [OK] we need to make the toolbars match the Dialog.
  • We need not just the dialog selections, but the list data too.
  • It's a tradeoff--should we cache at the server or cache at the UI?.
  • Caching anywhere complicates the code.
  
  
• Vehicle Manager
  
  • Factory methods provide the combo and list models.
  • The UI used the models, but doesn't manage them.
  • On clicking [OK] setCombosFromLists() copies data and selections.
  • Note the simple way of temporarily stopping the combo refreshing.
  • A guard statement in refreshMakeCombo() prevents the refresh.
  • In setLookupFromState() and setStateFromLookup(), substitute "Toolbars" for "State".
  • Combo models incorporate selecion; list models do not--they have separate list selection models.
  • Our LookupListModel contains a ListSelectionModel.
  
  
• Lookup Manager
  
  • As a mid-level manager, LookupManager handles lookups in general.
  • Low-level managers (Parts, Labor, Inter) handle the lookup details.
  • LookupManager is the keeper of the list (of previous lookups).
  • Note in doLookupByIndex() that LookupManager delegates to the lower level managers.
  • Doing a dialog entails three steps:
    1. Create the dialog.
    2. Show the dialog--this blocks until the user closes.
    3. If not canceled(), do what the user requests.
  • Notice how simply you can serialize objects. That's why I prefer serialization for Q&D state persistence.
  • When you serialize an object, you serialize the whole tree--all references are preserved, providing the objects referenced are Serializable.
  • Serializable is a marker interface. It has no methods to implement.
  
  

Servers and Data

• The Lookup Object
  
  • Lookup objects have a Type, and a Date stamp.
  • Only InterLookup, LaborLookup, and PartsLookup are concrete.
  • isDescLookup() or Group lookup.
  • isDescByGroup() or by the Description itself.
  • isOrderByManf() or order by description.
  • PartsLookup and LaborLookup implement all the interface methods..
  
  
• JavaAPI Wrapper
  
  • These classes are not yet complete.
  • Parameters and return types are generally typesafe.
  • getParts() returns a heterogeneous array of Objects.
  • getQuestions() of course means "getPartsSpecificConditions".
  
  
• Performing a Lookup
  
  • In the case of the Lookup Dialog, nothing happens until the user clicks [OK], but with toolbars, every control can triger a new lookup.
  • This (approximately) is the sequence of events during a lookup.
  • These are the main characters.
  • PartsLookupManager owns a Lookup--the "current" lookup.
  • groupChange() updates the current lookup and calls doLookup().
  • invokeLater() pops a Runnable into the Event Queue. Other pending events, such as hiding the combo's dropdown, will execute first.
  • Meanwhile screen repainting continues, as always, on a separate thread.