UIX: Anybody have example of lovValidate checking against db?

Question

Hi gang
Does anybody have an example in UIX of using the lovValidate event to check a user entered messageLovInput value against the database, and if an invalid entry, via showWindow, forcing the user to select a value from the LOV?
Any help appreciated.
CM.

Answer 1

Okay, IperProcedureCode is the attribute in the VO that the lovInput is attached to. When you write bindings.<attributeName> in your EL, then this comes out as the DCControlBinding (or a subclass) in the Java code. So I pass the binding into the EL method in order to get access to the binding container, the AM, the VO ... whatever.
I have defined that EL method myself and it's no big deal. You add an UI extension in your UIX config and in that UI extension you register the new EL functions.
This is the EL class:
package com.ge.med.bone.el;
import ...
public class DataUtilityElFunctions {
  public static Method lookupInput;
  static {
    try {
      lookupInput = DataUtilityElFunctions.class.getDeclaredMethod( "_lookupInput",
                                                                    new Class[] {
                                                                      JUCtrlAttrsBinding.class,
                                                                      String.class,
                                                                      String.class,
                                                                      String.class
    } catch( NoSuchMethodException nsme ) {
      // Will never ever happen!
  //~ Constructors ***********************************************************************
  private DataUtilityElFunctions(  ) {}
  //~ Methods ****************************************************************************
   * Performs the lookup of user input.
   * @param binding The JUCtrlsAttrsBinding as used to bind text fields.
   * @param input The input the user has typed in.
   * @param setResult Pass 'true' if you want to set the result automatically in the
   *        attribute.
   * @param clearUnresolved Pass 'true' if you want the attribute to be cleared if it
   *        couldn't be resolved. Needs setResult='true' to work.
   * @return The looked up value or null if none found or ambigous.
  public static String _lookupInput( JUCtrlAttrsBinding binding,
                                     String input,
                                     String setResult,
                                     String clearUnresolved ) {
    String lookupResult = null;
    String attributeName = null;
    if( ( binding != null ) && ( input != null ) && ( input.length(  ) > 0 ) ) {
      BaseViewObject viewObject = (BaseViewObject)binding.getViewObject(  );
      DCBindingContainer container = binding.getBindingContainer(  );
      attributeName = binding.getAttributeNames(  )[ 0 ];
      BaseViewObject vo = (BaseViewObject)binding.getViewObject(  );
      BaseAttributeDef attributeDef = vo.findExtendedAttributeDef( attributeName );
      if( attributeDef != null ) {
        TextLookupData data = new TextLookupData( container, attributeDef, attributeDef,
                                                  true );
        data.lookupInput( input );
        if( data.isAllLookedUp(  ) ) {
          LookupDataItem item = (LookupDataItem)data.getLookedUpDataItems(  ).get( 0 );
          lookupResult = item.getResolvedObject(  ).toString(  );
      if( ( setResult != null ) && setResult.equals( "true" ) ) {
        if( lookupResult != null ) {
          binding.setInputValue( lookupResult );
        } else if( ( clearUnresolved != null ) && clearUnresolved.equals( "true" ) ) {
          binding.setInputValue( null );
        } else {
          binding.setInputValue( input );
    return lookupResult;
}We use our own VO base class, don't let that disturb you. The TextLookupData class encapsulates the lookup. We already use this class in our Swing client to do the lookup. It uses the container to get to the AM, then creates the lookup VO, sets a nifty where-clause, executes the VO and then returns the lookup result after removing the lookup VO again.
Again, no big deal.
The EL function, as you can see, returns the result of the lookup or null if the lookup failed. I use this in the UIX event handler to determine whether the attribute that controls the LOV window showing should be set to "true" or "false".
param.seachText contains the user input at the moment of validation.
Of course, you could move the lookup stuff in a AM method if you prefer it that way.
The UI extension class:
package com.ge.med.bone.uix;
import ...
public class BoneUiExtension implements UIExtension {
  //~ Constructors ***********************************************************************
   * Default constructor.<br> Creates the object and sets the parameters.<br>
  public BoneUiExtension(  ) {}
  //~ Methods ****************************************************************************
   * Registers the parser manager
   * @param manager The parser manager.
  public void registerSelf( ParserManager manager ) {
    manager.registerFunction( "http://xmlns.med.ge.com/centricity/bone/el/data",
                              "lookupInput",
                              new JavaMethod( DataUtilityElFunctions.lookupInput ) );
   * Register renderers with the look-and-feels.
   * @param laf The LAF or LAF extension to register with.
  public void registerSelf( LookAndFeel laf ) {}
}and in our uix-config.xml:
      <extension-class>
        com.ge.med.bone.uix.BoneUiExtension
      </extension-class>In the UIX page that holds the lovInput I just add the namespace:
xmlns:dataEl="http://xmlns.med.ge.com/centricity/bone/el/data"Now I can simply call the EL function whenever I like. This EL stuff is pretty handy. I also use it to get custom labels that we defined for our attributes and to access resource bundles.
The input field contains a (medical) procedure code. Just for user convenience I also display read-only the description of the medical procedure after validation. This read-only field (with id _procedureName) needs a refresh after validation/lookup. That's why it's a partial refresh target.
That must be the longest posting I ever posted here :o)
Sascha