Search Results form_item_id




Overview
Explore in AI Chat

Overview

APPS.HR_FORM_ITEM_INFO is an Oracle E-Business Suite PL/SQL package body that supplies runtime metadata about the items defined on Oracle Forms-based application forms. Its principal business purpose is to make form structure and item-level attributes available to calling code without requiring each caller to query the underlying Forms repository tables directly. The package is a member of the HR family of form-metadata utilities and is classified as an OTHER API in the ETRM repository for release 12.2.2, indicating that it is an internal helper package rather than a public, supported extension point.

The package exposes a single global collection type, t_form_items, which is used to return the complete item inventory for a given application and form. The naming convention of the underlying source file (hrfiminf.pkb) is consistent with the Oracle Forms metadata layer, and the object header dates from the 11.5 code line, which explains its presence and continued operation across both the 12.1.1 and 12.2.2 releases.

Key Procedures and Functions

ETRM documents two callable units within this package body:

  • FORM_ITEMS — This function returns a collection of item records for a specified application and form. It opens a cursor that joins the form item definitions to their canvas, tab page, property, and translation records so that the caller receives a consolidated view of each item, including its identity, display classification, and presentation attributes. The returned collection is used by callers that need to iterate across all items on a form, for example when generating form-related setup data or transferring form metadata between environments.
  • FULL_ITEM_NAME — This function resolves and returns the fully qualified item name for a form item. Oracle Forms item names may be stored in a decomposed form, and callers frequently require the complete, block-qualified identifier. This function encapsulates that resolution so that callers do not have to reconstruct the name themselves.

Both units are declared in the package specification and implemented in the body. No parameter lists are reproduced here, as the documented metadata does not enumerate them in a supported API form.

Tables Accessed

The package reads from the following tables through APPS synonyms:

  • FND_APPLICATION and FND_FORM — used to validate and resolve the application and form context passed into the item query.
  • HR_FORM_ITEMS_B — the base table of form item definitions, supplying the item identifier, full item name, item type, and radio button name.
  • HR_FORM_CANVASES_B and HR_FORM_TAB_PAGES_B — supply canvas and tab page names used to locate items within the form layout.
  • HR_ITEM_PROPERTIES_B and HR_ITEM_PROPERTIES_TL — supply the item presentation and behavior attributes (alignment, bevel, case restriction, enabled flag, format mask, height, prompt properties) plus the translated label, prompt, and default value text.
  • PLITBLM — an internal Forms metadata table consulted in the name-resolution logic.

The package is read-only with respect to these objects; it does not perform inserts, updates, or deletes.

Usage Notes

HR_FORM_ITEM_INFO is an internal helper. ETRM records that it is referenced by two other packages, which confirms that its consumers are other server-side PL/SQL modules rather than end users. Typical invocation patterns include:

  • Form-driven and metadata-generation routines that need to enumerate the items on a form and their display properties.
  • Setup or migration utilities that copy form item definitions between instances and require a normalized, resolved item name.
  • Custom code that must report on form structure, for example impact analysis before a form customization.

Because the package is not classified as a public API, customizations should avoid depending on it directly; equivalent queries against the HR form metadata tables are more stable across patches. Callers should also note that the function returns a PL/SQL collection declared in the package, so any consumer must reference the package type when declaring its own variables.