A script-enabled browser is required for this page to function properly.

Writing a Custom Data Type Encoder

A custom encoder is a very simple piece of Java which has to implement the oracle.forms.beans.Encoder interface. However, rather than directly implementing this interface it is better to subclass the oracle.forms.beans.FormsEncoder class which has already implemented most of the basic functionality.

If you extend the FormsEncoder class, then your Encoder will only have to contain a constructor and, at most, two methods. This section illustrates the various pieces of code required by creating an encoder to handle the Fraction class.

Here is the code for a Fraction object for which an encoder is needed:

  
public class Fraction extends Object
  {
    private float mFraction;
    private int mNumerator, mDenominator;
  /**
  * Constructor
  */
     public Fraction(int numerator, int denominator)
     {
      mFraction = (float)numerator/denominator;
      mNumerator = numerator;
      mDenominator = denominator;
    }
	
    public float getValue()
    {
      return mFraction;
    }

    public String toString()
    {
      return new String(mNumerator + "/" + mDenominator);
    }
  }

The constructor for the new class should call the constructor in the FormsEncoder superclass, passing the Class of the class being encoded as an argument:

public class FractionEncoder extends FormsEncoder
  {  
    public FractionEncoder()
    {
        super(Fraction.class);
        //Do any other stuff here
    }
  ... 

As well as the constructor, the encoder has to provide implementations for two methods that are specific to the class being encoded—fromString() which takes a string version of the object as provided from PL/SQL and constructs a new instance of the object based on that information. And a toString() method which does the reverse, rendering the object into a string form that PL/SQL can use.

In many cases the native toString() method on the underlying object will be sufficient. If this is the case, your encoder will not have to implement a toString() method explicitly as the FormsEncoder implementation of toString() calls the object's own toString() method.

Here are the fromString() and toString() methods for the FractionEncoder. The PL/SQL string form of the fraction object is how a fraction would be written, for example, "2/3" or "4/15". So, the fromString() and toString() methods convert between that string format and an actual Fraction object:


public Object fromString(String parm1)
  {
    int numerator,denominator;
    int split = parm1.indexOf('/');
    // parse the string into two ints, in this
     // case we expect the string format to be
     // numerator/denominator e.g. "1/4" or "2/3"
    try
    {
      numerator = Integer.parseInt(parm1.substring(0,split));
      denominator = Integer.parseInt(parm1.substring(split+1));
    }
      catch ( NumberFormatException nfe )
      {
        return ( null );
      }
    //Create a new Fraction Object based on those ints
    return new Fraction(numerator,denominator);
  }


public String toString(Object parm1)
  {
    //Simply call the toString method of the
     //Fraction class as this already returns
     //the format that we want
    return parm1.toString();
  }

In this case, you would not have to code your own toString() method in the encoder because the class you are extending, FormsEncoder, already provides the correct implementation.

It is important to note that Encoders should handle any exceptions that might be raised (in the case of the FractionEncoder above, NumberFormatException). The best approach to take when facing an exception is to simply return null. You can optionally use System.out.println() to report the error to the Java Console for debugging purposes.


Writing a Custom Event Encoder

Registering a Custom Encoder