General

Summary of how to script the system.

Scripting in Exolynk

Scriptingin exolynk is done with the rune scripting language. This language can be executed inside the browser and server. Scripts which are executed in the browser frontend are called Workflows within Exolynk. Scripts which are executed in the backend on the server are called Services.

Custom script workflows and services can be either created for a specific model or as global scripts within the settings.

The oAuth2 authentification method also executes an service. After the successfull receifel of a oAuth2-key by exolynk, you can fetch aditional data from the 3rd party authentofcation system, to match the key to a specific user.

Workflows

A workflow should consist of 3 base functions. The first one is the show() function. This function should return a true when the workflow should be shown to the user and can be executed. When the function returns false or an error it will not show the workflow to a user. This function needs to be pub and is not supporting async.

pub fn show() {
    return true;
}

The main function which will be executed when a user clicks the workflow button is main(). The function can return any value and it's good practice to return ok Ok(()). This function needs to be pub and async.

pub async fn main() {
    Ok(())
}

The last base function is test(). This function is executed while developing the workflow. This function needs to be pub and async.

pub async fn test() {
    Ok(())
}

Services

Services consist only of the main() and test() functions. The test() function will be executed while developing. The main() function is called by rpc calls either from Websocket, Rest or the server itself. The amount of parametrs need to match the amount of values provided by a rpc call.

pub async fn main(number, text) {
    Ok(())
}

pub async fn test() {
    main(123, "example").await?;
    Ok(())
}

Global Service Trigger

Within the settings of an environment a user can define global workflows and services. These global services can be automatically called by the server either every full hour or every midnight. This can be used to reset states of records or perform other kind of logic in a regular basis.

Function hooks / reserved scripts

Exolynk uses specific script idents to identify special hook functions. These functions are getting called automatically on specific events, when defined. All hooks are only valid within a model as of now.

Workflow hook: render

This workflow is triggered whenever a page/record or home layout will be rendered. You have the possibility to change the rendering dom before the actual rendering is happening.

/// This function should not be shown in the actionbar
pub fn show() {
    false
}

pub async fn main(dom) {
    let childs = dom.children;
    let msg = exo::dom::RawHtml::new();
    msg.html = "<h1>Welcome User</h1>";
    childs.push(msg);
    dom.children = childs;
    dom
}

pub async fn test() {}

Workflow & Service hook: new_record()

This workflow/service is triggered whenever the user has created a new record. The new record can be received in the normal way with exo::get_record() -> Record.

/// Normal main function
pub async fn main() {
    // get the new record over api
    let record = exo::get_record()?;
    // debug print it
    dbg(record);
    // TODO: Extend this record with custom logic
}

Workflow hook: edit()

This workflow is overriting the normal edit button for a record. This allows to hide the edit button when specific user_rights or based upon other criterias. In addition this workflow is responsible to set the edit state on it's own when available.

Please not that only the UI edit button will not be visible. This is not a safe solution to prevent users to execute specific funtions. This always need to be done within a service.

pub fn show() {
    !exo::ui::is_edit()
}

pub async fn main() {
    exo::ui::set_edit(true);
}

pub async fn test() {}

Workflow hook: open()

This workflow is overriting the normal open button for a record. This allows to hide the open button when specific user_rights or based upon other criterias. In addition this workflow is responsible to set the open state on it's own when available.

pub fn show() {
    false
}

pub async fn main() {}

pub async fn test() {}

Workflow: Dynamic Variables

Dynamic variables can trigger a workflow to calculate a value in realtime. This workflow is triggered whenever a user changes the value or on the inital rendering. These workflows need to receive to old and new variable. In addition it need to return a Value or Variable which should be rendered.

pub fn show() {
    false
}

pub async fn main(old, new) {
    "Always return this fixed string"
}

pub async fn test() {}

Service hook: update_value

This model service is called, whenever a user want's to change a value of a record. When this service is available it's responsible to apply the changes to the corresponding record. The input parameter are the ident of the value to change and the new value.

pub async fn main(ident, value) {
    let record = exo::get_record()?;
    exo::db::update_record_value(record.uuid, ident, value).await?;
    Ok(())
}

pub async fn test() {}

Service hook: value_changed

This model service is called, whenever a value of a record has already changed. The input parameter are the old and new Variable of the record.

pub async fn main(old, new) {
    let record = exo::get_record()?;
    exo::db::update_record_value(record.uuid, "text", "Always this text").await?;
    Ok(())
}

pub async fn test() {}