__render_from_workflow ( { wf_id, wf_info, wf_action } )

Internal method that renders the ui components from the current workflow state. The info about the current workflow can be passed as a workflow info hash as returned by the get_workflow_info api method or simply the workflow id. In states with multiple action, the wf_action parameter can tell the method to proceed with this state.

activity selection

If a state has multiple available activities, and no activity is given via wf_action, the page includes the content of the description tag of the state (or the workflow) and a list of buttons rendered from the description of the available actions. For actions without a description tag, the action name is used. If a user clicks one of the buttons, the call gets dispatched to the action_select method.

activity rendering

If the state has only one available activity or wf_action is given, the method loads the list of input fields from the workflow definition and renders one form field per parameter, exisiting context values are filled in.

The type attribute tells how to render the field, accepted basic html types are

    text, hidden, password, textarea, select, checkbox

TODO: stuff below not implemented yet!

For select and checkbox you need to pass suitable options using the source_list or source_class attribute as described in the Workflow manual.

TODO: Meta definitons, custom config

custom handler

You can override the default rendering by setting the uihandle attribute either in the state or in the action defintion. A handler on the state level will always be called regardless of the internal workflow state, a handler on the action level gets called only if the action is selected by above means.

__get_action_buttons

For states having multiple actions, this helper renders a set of buttons to dispatch to the next action. It expects a workflow info structure as single parameter and returns a ref to a list to be put in the buttons field.

__render_input_field

Render the UI code for a input field from the server sided definition. Does translation of labels and mangles values for multi-valued componentes.

This method might dynamically create additional "helper" fields on-the-fly (usually of type hidden) and may thus return a list with several field definitions.

The first returned item is always the one corresponding to the workflow field.

__delegate_call

Used to delegate the rendering to another class, requires the method to dispatch to as string (class + method using the :: notation) and a ref to the args to be passed. If called from within an action, the name of the action is passed as additonal parameter.

__render_result_list

Helper to render the output result list from a sql query result. adds exception/paused label to the state column and status class based on proc and wf state.

__render_list_spec

Create array to pass to UI from specification in config file

__render_fields

__render_workflow_info

Render the technical info of a workflow (state, proc_state, etc). Expects a wf_info structure and optional a wfdetail_config, will fallback to the default display if this is not given.

__render_creator_tooltip

Expects the userid of a creator and the field definition.

If the field has yaml_template set, the template is parsed with the value of the creator given as key creator in the parameter hash. If the resulting data structure is a hash and has a non-empty key value, it is used as value for the field.

If the field has template set, the result of this template is used as tooltip for the field, the literal value given as creator is used as the visible value. If the namespace of the item is certid, the value will be created as link pointing to the certificate details popup.

If neither one is set, the creator() method from the "Metadata" Plugin is used as default renderer.

In case the template does not provide a usable value, the tooltip will show an error message, depending on weather the creator string has a namespace tag or not.

State with default rendering

    <state name="DATA_LOADED">
        <description>I18N_OPENXPKI_WF_STATE_CHANGE_METADATA_LOADED</description>
        <action name="changemeta_update" resulting_state="DATA_UPDATE"/>
        <action name="changemeta_persist" resulting_state="SUCCESS"/>
    </state>
    ...
    <action name="changemeta_update"
        class="OpenXPKI::Server::Workflow::Activity::Noop"
        description="I18N_OPENXPKI_ACTION_UPDATE_METADATA">
        <field name="metadata_update" />
    </action>
    <action name="changemeta_persist"
        class="OpenXPKI::Server::Workflow::Activity::PersistData">
    </action>

When reached first, a page with the text from the description tag and two buttons will appear. The update button has I18N_OPENXPKI_ACTION_UPDATE_METADATA as label an after pushing it, a form with one text field will be rendered. The persist button has no description and will have the action name changemeta_persist as label. As it has no input fields, the workflow will go to the next state without further ui interaction.

State with custom rendering

    <state name="DATA_LOADED" uihandle="OpenXPKI::Client::UI::Workflow::Metadata::render_current_data">
    ....
    </state>

Regardless of what the rest of the state looks like, as soon as the state is reached, the render_current_data method is called.

Action with custom rendering

    <state name="DATA_LOADED">
        <description>I18N_OPENXPKI_WF_STATE_CHANGE_METADATA_LOADED</description>
        <action name="changemeta_update" resulting_state="DATA_UPDATE"/>
        <action name="changemeta_persist" resulting_state="SUCCESS"/>
    </state>
    <action name="changemeta_update"
        class="OpenXPKI::Server::Workflow::Activity::Noop"
        uihandle="OpenXPKI::Client::UI::Workflow::Metadata::render_update_form"
        description="I18N_OPENXPKI_ACTION_UPDATE_METADATA_ACTION">
        <field name="metadata_update"/>
    </action>

While no action is selected, this will behave as the default rendering and show two buttons. After the changemeta_update button was clicked, it calls the render_update_form method. Note: The uihandle does not affect the target of the form submission so you either need to properly setup the environment to use the default action (see action_index) or set the wf_handler to a custom method for parsing the form data.