Func type templates

Custom functions (func type templates)

Custom func template can be used as functions. These templates only return the specified content and ignore the rest of the string content on them.

Note that func template do not have access to the usual .Data values in the template, anything that is to be used in there would need to be passed as arguments or loaded in the func with api calls.

Returning values

We specify the content we want to return with .Return in the func type templates.

For example (da-test-func):

This string will not be returned.

{{ .Return "this-will-be-returned" }}

And to call the func template we use it like this (da-test-page):

{{ .Tools.Func "da-test-func" }}

The output printed to the template here would be “this-will-be-returned”

Note that the function will return the first .Return value, anything that is after the first return will not be executed.

{{ .Return "this-will-be-returned" }}
{{ .Return "this-will-never-get-returned" }}

We can use regular template logic to pick the first value

{{ if $something }}
    {{ .Return "will return if the condition is true" }}
{{ end }}
{{ .Return "if the condition is not true then it will return this instead" }}

Reading arguments

We can read arguments with the .Arg {index} command. Note that out of index arguments will always return an empty string.

To pass arguments to the functions we append the values to the func like with regular templates (da-test-page):

{{ .Tools.Func "da-test-func" "some-string" 2025 }}

To read the arguments in the func template (da-test-func):

<!-- Will get the value of "some-string" -->
{{ $argument1 := .Arg 0 }}
<!-- Will get the value of 2025 -->
{{ $argument2 := .Arg 1 }}

Api calls in functions

Func types have access to the app state functionality. This gives us better control over the api calls. Read about the functionality in the App state section.

Error

On extreme cases we can also make the function fail the entire flow. Calling this will display the goerp error page with the given error message.

Nothing after the error call will execute.

{{ .Error “my error message” }}

Subsections of Func type templates

App state

App state

Note

The app state object is currently only available in the func type templates

The app state object can be used to make immediate api calls using the same dynamic api instructions. The object can also store the instructions and results for later use.

Simple call api (.Fetch)

This method does not store the instructions or the result. Use for one time api calls that always need to have fresh data.

The call has 1 argument, that it expects to be a map of dynamic api instructions. Same as form inputs or static url configuration values.

For example: “ErplyApi.Api.Post.myRequest1”: “getProducts”

Note that the instructions support all the same functionalities as the regular dynamic api (multiple requests, grouping, chaining etc).

Use the ‘mkMap’ helper to create the instructions set.

{{ $getProducts := mkMap "ErplyApi.Api.Post.myRequest1" "getProducts" }}
{{ $calls := .Tools.AppData.Fetch $getProducts }}

Using the fetch here will run the instructions immediately and will not proceed with template execution until the api calls are complete. We can use the results immediately in the template code.

The calls object organizes the api calls from the instructions similarly to dynamic api. For example, we called erply api with our own request name “myRequest1”, so we will read the results like this:

{{ $result := $calls.ErplyApi.myRequest1.Response.Get "records" }}

If the instruction set included more api calls then the results would be available according to the api and request names.

Call api and store instructions and results (.FetchAndStore)

This method stores the instructions and the results. We can then use shorter versions of the call to run the instructions again for fresh data or return the already completed results.

Note

Note the store will share data based on the following rules:

  1. Regular - client code, app and current session
  2. Automation - each automation will have a separate context (2 separate automations cannot share data)
  3. Shared - client code and app
{{ $getProducts := mkMap "ErplyApi.Api.Post.myRequest1" "getProducts" }}
{{ $calls := .Tools.AppData.FetchAndStore $getProducts }}

{{ $result := $calls.ErplyApi.myRequest1.Response.Get "records" }}
Note

Like all store functions, they support an optional second arguments (string value). That can be used to group the instructions. We can then use the given name to either run the same instructions again or return the stored results.

If we do not provide the name value then by default all instructions will be set to the empty name (all further updates and runs will overwrite the values).

Named example:

{{ $getProducts := mkMap "ErplyApi.Api.Post.myRequest1" "getProducts" }}
{{ $calls := .Tools.AppData.FetchAndStore $getProducts "myNamespace" }}

{{ $result := $calls.ErplyApi.myRequest1.Response.Get "records" }}

Call api using stored instructions

This method runs stored instructions and returns fresh data. Note that the call will not return anything if we do not have any stored instructions.

Using empty namespace (default):

{{ $calls := .Tools.AppData.FetchStored }}

Using a custom namespace:

{{ $calls := .Tools.AppData.FetchStored "myNamespace" }}

Return stored results or re-run if nothing stored

This method returns stored results or re-runs the stored instructions if there are not stored results. Note that the call will not return anything if we do not have any stored instructions.

Using empty namespace (default):

{{ $calls := .Tools.AppData.FetchStoredResults }}

Using a custom namespace:

{{ $calls := .Tools.AppData.FetchStoredResults "myNamespace" }}

To refresh the stored results we can just run the FetchAndStore call on the same set name.

Store instructions without running them immediately

Stores the call instructions but does not run them immediately. Can be used to initialize api calls for later use.

In this example we store 2 different sets with “p1” and “p2” names, but we do not run them. We can later than just use the FetchStoredResults to run the calls.

{{ $getProducts := mkMap 
    "ErplyApi.Api.Post.myRequest1" "getProducts" 
}}
{{ .Tools.AppData.Store $getProducts "p1" }}

{{ $getProducts2 := mkMap
    "ErplyApi.Api.Post.myRequest1" "getProducts"
    "ErplyApi.Api.PostParam.myRequest1.productID" "15"
}}
{{ .Tools.AppData.Store $getProducts2 "p2" }}

For example, we can create a condition here to switch between the calls.

{{ $results := mkMap }}
{{ if eq $byNameValue "p1" }}
    {{ $results = .Tools.AppData.FetchStoredResults "p1" }}
{{ else }}
    {{ $results = .Tools.AppData.FetchStoredResults "p2" }}
{{ end }}
{{ .Return ($results.ErplyApi.myRequest1.Response.Get "records") }}

Patch stored instructions

If we call the store function on an existing namespace then it will replace all values. If we want to just replace a single value in an existing set then we can use the patch call.

Expecting that we have previously stored and instruction set to “p1” name:

{{ $getProducts2 := mkMap
    "ErplyApi.Api.Post.myRequest1" "getProducts"
    "ErplyApi.Api.PostParam.myRequest1.productID" "15"
}}
{{ .Tools.AppData.Store $getProducts2 "p2" }}

We can use the patch call to just replace the productID instruction

{{ $getProducts2 := mkMap
"ErplyApi.Api.PostParam.myRequest1.productID" "16"
}}
{{ .Tools.AppData.PatchStore $getProducts2 "p2" }}

Patch call will replace the value if it exists and add as new if it does not.

Shared variants

Note

Shared variants share the results and instructions on the same client code and application. So only use for data that is meant to be shared.

On automations the shared variant has no effect as data is still only available to the same automation.

This feature can speed up application loads considerably as api call needs to be done only once between multiple sessions. For use in stores for data that does not really change. Making a fresh call on the same set can be used to refresh the set.

Functionality of the shared sets is the same as the other store capable functions, just append the name with Shared.

  1. SharedFetchAndStore
  2. SharedFetchStored
  3. SharedFetchStoredResults
  4. SharedStore
  5. SharedPatchStore