Package de.xima.fc.prompt.service.support

The prompt API is kept intentionally low-level to support a wide range of use cases. This package contains additional classes that you can use to implement the API interfaces in a more convenient way. You are not required to use any of these classes, but we recommend its use if possible. This also helps to ensure that different implementations follow the same conventions and behave similarly.

This package contains the following utilities:

Mixins for prompt connection and query models

Prompts consist of 2 parts, a connection configuration and a query configuration. The connection configuration defines how to connect to the prompt service provider, the query configuration defines the prompt to execute. Each prompt service handler can have a different type of configuration, and usually uses a custom data model class to represent the configuration.

In practice, different types of prompt services will often share similar configuration options, such as e.g. "API key" or a "prompt text". To increase interoperability between different prompt service handlers, implementations should use the same property name for similar configuration options. This way, when the user switches between different prompt services, the configuration data can be preserved. To facilitate this, this package contains mixin interfaces that define common configuration options with a consistent property name. Prompt service handler implementations are encouraged to use these mixins when possible.

For mixins for connection configurations, use de.xima.fc.prompt.conventions IPromptConnectionConfig_*, e.g. IPromptConnectionConfig_ApiKey.

For mixins for query configurations, use de.xima.fc.prompt.conventions IPromptQueryConfig_*, e.g. IPromptQueryConfig_UserPrompt.

The Faces taglib with the namespace http://www.xima.de/taglib/xfc/prompt often also contains a corresponding component for editing the data defined by a mixin. See the class documentation of the mixin for details.

Common option names

Often, prompt services can perform a multitude of tasks, such as generating text, generating images, transcribing speech, and so on. A common pattern for prompt service implementations is to let the user select the task to perform as part of the query configuration UI. The IPromptQueryConfig_Task mixin provides a String property for specifying the task name.

While it is up to each prompt service handler implementation how to call different tasks, we encourage the use of common task names to increase interoperability between different prompt service handlers. CommonPromptTask defines constants with standard names for common tasks. Use these if possible.

In addition, there are other classes with constants for common option values:

Common output properties

CommonPromptOutputProperty contains constants with common names for prompt output properties, such as the main text answer. You can use these for the computeQueryOutput method of a prompt service handler implementations. Use of these properties is not mandatory, but encouraged to improve interoperability between different prompt service implementations.

JSON schema service

Models respond to prompt with a plain text response. While that may be sufficient for simple use cases, more complex scenarios often require structured data, e.g. when you want to access the data programmatically. Some prompt services now offer the ability to define a JSON schema that describes the expected structure of the response. The prompt service will then respond with a JSON object that conforms to the schema.

The CDI-injectable IPromptJsonSchemaService provides various utility methods for working with JSON schemas in the context of prompts, such as extracting the JSON schema from a configured IPromptQueryConfig_JsonSchemaOutput; or transforming a JSON schema to be compatible with the restrictions imposed by a specific prompt service provider.

Prompt parameters service

The CDI-injectable IPromptParametersService provides common utility methods often needed by prompt service handlers for their input and output parameters, especially for implementing the computeQueryInput and computeQueryInput methods.

Execution commons service

The CDI-injectable IPromptExecutionCommonsService provides common utility methods often needed by the executePromptQuery method of prompt service handlers.

Mixins for prompt service handlers

The prompt engine is implementation-agnostic and can work with any prompt service handler that implements the IPromptServiceHandler interface. It does not know about any details from specific implementations. As a result, the prompt service handler interface defines a wide-range of methods, so that implementations can provide the necessary functionality.

To ease the implementation of prompt service handlers, this package contains mixin interfaces that provide default implementations for common functionalities, so that these do not have to be re-implemented by each prompt service handler.

PromptServiceHandlerMixin_JsonConfig
Mixin for handlers that wish to use a model class that can be serialized as JSON. See the class documentation of the mixin for details.
Since:
8.5.0