Interface StudioAiChatElements


@StudioUiKit public interface StudioAiChatElements
  • Field Summary

    Fields
    Modifier and Type
    Field
    Description
    static final String
     
    static final String
     
    static final String
     
    static final String
     
    static final String
     
    static final String
    The designer resolves an icon path only against the declaring kit artifact, so the framework paths — including @StudioElement's own unknownComponent.svg default — render as nothing from here.
    static final String
     
    static final String
     
    static final String
     
    static final String
     
    static final String
     
  • Method Summary

    Modifier and Type
    Method
    Description
    void
     
    void
     
    void
     
    void
     
    void
    The chat's own screen-reader announcements.
    void
    The composer's localization inside the chat's i18n — the same properties as aiMessageInput's own element, because it is the same bean.
    void
    The transcript's localization inside the chat's i18n — the same properties as aiMessageList's own element, because it is the same bean.
    void
     
    void
     
    void
    Unlike aiMessageInput's prefix / suffix, these six names are the add-on's own, so there is no framework descriptor being overridden and no need for the caveat the aiMessageInputPrefix holder carries.
    void
     
    void
    The multi-line spelling of the system prompt, modelled on aiCodeBlock's code element: present means it wins over the attribute.
    void
     
    void
    The declarative localization surface: one i18n element per component, its properties mirroring the fields of that component's own *I18n bean.
    void
    The code blocks rendered inside messages: codeBlock is a field of AiMessageListI18n, of the code block's own i18n type, so it nests under the message list's element — the standalone one and the one inside the chat's alike — rather than flattening four more attributes onto either.
    void
    The action row inside either per-role group.
    void
     
    void
    Like thinkingIndicator, header / footer are slots this add-on invents on aiMessageInput, so there is no framework descriptor to override and no need for the caveat the prefix / suffix holders carry.
    void
     
    void
    Unlike tooltip, the framework declares prefix / suffix against the HasPrefix / HasSuffix interfaces, which this component implements — so its descriptors already match and would write the elements unprefixed, invalid against this add-on's schema, whose locally declared elements are qualified.
    void
     
    void
    The framework's own tooltip element enumerates its hosts by FQN and cannot know this add-on's components, so the element is re-declared here for aiMessageInput.
    void
    Carries an identifier so the nested codeBlock element can target it without naming a class — the same mechanism thinkingStage uses to reach its container.
    void
    A slot this add-on invents, so there is no framework descriptor to override — one entry is the whole story.
    void
     
    void
    The add-on's first container elements.
    void
    The two per-role action containers, declared as element groups rather than @StudioActionsGroup.
  • Field Details

  • Method Details

    • aiCodeBlockCode

      void aiCodeBlockCode()
    • aiMessageInputTooltip

      void aiMessageInputTooltip()
      The framework's own tooltip element enumerates its hosts by FQN and cannot know this add-on's components, so the element is re-declared here for aiMessageInput.
    • aiMessageInputPrefix

      void aiMessageInputPrefix()
      Unlike tooltip, the framework declares prefix / suffix against the HasPrefix / HasSuffix interfaces, which this component implements — so its descriptors already match and would write the elements unprefixed, invalid against this add-on's schema, whose locally declared elements are qualified. These entries are meant to override them by being more specific, the mechanism the @StudioElementsGroup javadoc documents. For a plain element that was an inference; a live Studio pass has since confirmed it — the designer writes <aichat:prefix> and <aichat:suffix>, and the view loads.
    • aiMessageInputSuffix

      void aiMessageInputSuffix()
    • aiMessageInputHeader

      void aiMessageInputHeader()
      Like thinkingIndicator, header / footer are slots this add-on invents on aiMessageInput, so there is no framework descriptor to override and no need for the caveat the prefix / suffix holders carry.
    • aiMessageInputFooter

      void aiMessageInputFooter()
    • aiThinkingIndicator

      void aiThinkingIndicator()
      A slot this add-on invents, so there is no framework descriptor to override — one entry is the whole story. An empty element is meaningful (it clears the built-in indicator), which is why the child is optional rather than required.
    • aiThinkingStages

      void aiThinkingStages()
      The add-on's first container elements. Serves two hosts (AI_MESSAGE_LIST_FQN and AI_CHAT_FQN) under a single identifier, so children that target it (such as aiThinkingStage) reach both without being re-declared per component. The nesting is not observable from a compile — verify it in a live Studio pass.
    • aiThinkingStage

      void aiThinkingStage()
    • aiUserActions

      void aiUserActions()
      The two per-role action containers, declared as element groups rather than @StudioActionsGroup. The designer recognises only one actions group per host: with both declared that way, userActions resolved and assistantActions rendered as an unrecognised aichat:assistantActions, on AiMessageList and AiChat alike. Nothing in the framework or the other premium add-ons carries two on one host, and @StudioActionsGroup's xmlElement default of "actions" says the construct was meant to be the single one per component.

      An element group has no such limit — thinkingStages already serves both hosts — so both roles are reachable this way, at the cost of the action-type picker: the action row is an ordinary element (see aiMessageActionElement()) whose type is chosen from a property, not from a list of registered action types. The schema, the loaders and the runtime are untouched by this choice; it is a designer-side decision only.

      See Also:
    • aiAssistantActions

      void aiAssistantActions()
    • aiMessageActionElement

      void aiMessageActionElement()
      The action row inside either per-role group. An actions group supplies this row itself, from the @StudioAction types registered against it; an element group does not, so the element is declared here — see aiUserActions() for why the groups are element groups in the first place.

      The properties mirror aiMessageAction in ui.xsd one-for-one, which is the point: the five Action properties whose setters throw stay out, rather than being offered and then refused at load. type is OPTIONS and not ENUMERATION because the schema's own aiMessageActionTypeEnum is a union — an application's own action type has to stay valid.

    • aiChatActions

      void aiChatActions()
    • aiChatSystemPrompt

      void aiChatSystemPrompt()
      The multi-line spelling of the system prompt, modelled on aiCodeBlock's code element: present means it wins over the attribute.
    • aiChatInputPrefix

      void aiChatInputPrefix()
      Unlike aiMessageInput's prefix / suffix, these six names are the add-on's own, so there is no framework descriptor being overridden and no need for the caveat the aiMessageInputPrefix holder carries.
    • aiChatInputSuffix

      void aiChatInputSuffix()
    • aiChatInputHeader

      void aiChatInputHeader()
    • aiChatInputFooter

      void aiChatInputFooter()
    • aiChatEmptyStateHeader

      void aiChatEmptyStateHeader()
    • aiChatEmptyStateFooter

      void aiChatEmptyStateFooter()
    • aiCodeBlockI18n

      void aiCodeBlockI18n()
      The declarative localization surface: one i18n element per component, its properties mirroring the fields of that component's own *I18n bean. All four share the element name and this add-on's xmlns, and are told apart by target alone — four additions, not three overrides of the first.

      The beans nest (the list's holds the code block's, the chat's holds the input's and the list's), so the elements nest the same way, each reaching its container through an identifier. Every property is a LOCALIZED_STRING, so a msg:// key resolves in all three legs of the contract.

    • aiMessageInputI18n

      void aiMessageInputI18n()
    • aiMessageListI18n

      void aiMessageListI18n()
      Carries an identifier so the nested codeBlock element can target it without naming a class — the same mechanism thinkingStage uses to reach its container.
    • aiChatI18n

      void aiChatI18n()
      The chat's own screen-reader announcements. Everything the composer and the transcript can say lives on the nested messageInput and messageList elements below, of those components' own types — AiChatI18n holds their beans rather than restating their fields. Carries an identifier so both can target it without naming a class.
    • aiChatI18nMessageInput

      void aiChatI18nMessageInput()
      The composer's localization inside the chat's i18n — the same properties as aiMessageInput's own element, because it is the same bean.
    • aiChatI18nMessageList

      void aiChatI18nMessageList()
      The transcript's localization inside the chat's i18n — the same properties as aiMessageList's own element, because it is the same bean. Carries its own identifier so the nested codeBlock reaches it here too.
    • aiI18nCodeBlock

      void aiI18nCodeBlock()
      The code blocks rendered inside messages: codeBlock is a field of AiMessageListI18n, of the code block's own i18n type, so it nests under the message list's element — the standalone one and the one inside the chat's alike — rather than flattening four more attributes onto either. Its four properties are the code block's, because it is the same bean.