Scout/Concepts/LookupCall

Scout

Wiki Home

Website

Download • Git

Community

Forums • Blog • Twitter • G+

Bugzilla

Bugzilla

Lookup calls are mainly used by SmartFields and SmartColumns to look up single or multiple LookupRows.

• Class: LookupCall

Description

The Lookup call mechanism is used to lookup up a set of key-text pairs. Whereas the key can be of any Java type the text must be of the type String. Each entry in this set is called LookupRow. In addition to the key and the text a LookupRow can also define and icon, font, colors and a tooltiptext.

This schema explains the role of a LookupCall in a SmartField:

Input

Lookup calls provide different method to compute the set of LookupRows :

• getDataByKey(): Retrieves a single lookup row for a specific key value. Used by SmartFields and SmatColumns to get the display text for a given key value.
• getDataByText(): Retrieve multiple lookup rows which match a certain String. Used by SmartFields when the user starts to enter some text in the field.
• getDataByAll(): Retrieves all available lookup rows. Used by SmartFields when the user clicks on the browse icon.
• getDataByRec(): This can only be used for hierarchical lookup calls. It retrieves all available sub-tree lookup rows for a given parent.

Members

The Lookup call contains attributes (accessible with getter and setter) that can be used to compute the list of lookups rows. Out of the box you have:

• key: contains the key value when the lookup is queried by key.
• text: contains the text input in case of a text lookup (typically this is the text entered by the user smart field).
• all: contains the browse hint in case of a lookup by all (typically when a user click on the button to see all proposal in a smart field).
• rec: contains the key of the parent entry, in when the children of a node are loaded.
• master: contains the value of the master field (if a master field is associated to the field using the lookup call).

It is possible to add you own additional attributes, for example validityFrom, validityTo as date parameter. Just add them as field with getter and setter:

public class LanguageLookupCall extends LookupCall {
  //other stuff like serialVersionUID, Lookup Service definition...
 
  private Date m_validityFrom;
  private Date m_validityTo;
 
  @Override
  protected Class<? extends ILookupService> getConfiguredService() {
    return ILanguageLookupService.class;
  }
 
  public Date getValidityFrom() {
    return m_validityFrom;
  }
 
  public void setValidityFrom(Date validityFrom) {
    this.m_validityFrom = validityFrom;
  }
 
  public Date getValidityTo() {
    return m_validityTo;
  }
 
  public void setValidityTo(Date validityTo) {
    this.m_validityTo = validityTo;
  }
}

In this case, you might want to set your properties bevor the lookupcall query is sent. This can be done with the PrepareLookup event of the SmartField or the ListBox:

@Override
protected void execPrepareLookup(LookupCall call) throws ProcessingException {
  LanguageLookupCall c = (LanguageLookupCall) call;
  c.setValidityFrom(DateUtility.parse("2012-02-26", "yyyy-mm-dd"));
  c.setValidityTo(DateUtility.parse("2013-02-27", "yyyy-mm-dd"));
}

If you follow this pattern, you will consume the values in the server, by casting the call:

@Override
public LookupRow[] getDataByAll(LookupCall call) throws ProcessingException {
  LanguageLookupCall c = (LanguageLookupCall) call;
  Date validityFrom = c.getValidityFrom();
  Date validityTo = c.getValidityTo();
 
  //compute result: corresponding lookup rows (depending on validityFrom and validityTo).
  return result;
}

Type of lookup calls

With a Lookup Service

Delegation to the Lookup Service on server side.

They are not necessarily restricted to a fix number of records. Instead they should be favoured if the set of records is rather large.

Directy

Principe of the Local Lookup Calls

TODO
Explain and mention the execCreateLookupRows method

An example of this approach is when a SmartField or a SmartColumn is configured to be use with a CodeType. A CodeLookupCall is instantiated for the CodeType. It creates the LookupRows corresponding to the codes in the CodeType.

Overview

Properties

Defined with getConfiguredXxxxxx() methods.

• Service: Defines which service is used to retrieve lookup rows
• MasterRequired: Defines whether a master value must be set in order to query for multiple lookup rows

Code example

Using a LookupCall in a SmartField

public class ColorSmartField extends AbstractSmartField<String> {
  // other configuration of properties.
  @Override
  protected Class<? extends LookupCall<?>> getConfiguredLookupCall(){
    return ColorLookupCall.class;
  }
}

Accessing a LookupRow directly

It is possible to access a LookupRow direclty. In this example the input is a key (thisKey) and the method getDataByKey() is used. Before accessing the text, we ensure that a LookupRow has been retrived.

//Execute the LookupCall (using DataByKey)
LookupCall call = new MyLookupCall();
call.setKey(thisKey);
LookupRow[] rows=call.getDataByKey();
 
//Get the text (with a null check)
String text = null;
if(rows != null && rows.length > 0) {
  text = rows[0].getText();
}

See Also

• Lookup Row
• Lookup Service
• Local Lookup Calls
• Shared Plug-In