gramlot.

Course · Lesson 13 of 20

Call an endpoint

Send explicit arguments to a server method and handle both a returned value and a failure.

Reading · Practice2 sectionsPrerequisites: Format values without changing Data
Course contents
Orientation
  1. 01 Install Gramlot and create Hello world
  2. 02 Connect text and colour to Data
  3. 03 Explore Data and Source with the inspector
  4. 04 Use relative and symbolic paths, then dataFormula
  5. 05 Call the server with dataRpc and .remote
Start a project
  1. 01 Create your first project
  2. 02 Read and compose Source
  3. 03 Initialize structured Data
  4. 04 Connect fields and values
Build a form
  1. 05 Accept values, preserve drafts
  2. 06 Declare a calculation
  3. 07 Run an action at the right time
  4. 08 Name behavior and understand lifecycle
Compose an interface
  1. 09 Arrange an application with containers
  2. 10 Style the page you own
  3. 11 Publish messages and ask before acting
  4. 12 Format values without changing Data
Connect services
  1. 13 Call an endpoint
  2. 14 Load a Source fragment
  3. 15 Load Data when it is read
  4. 16 Save, restore and send Data deliberately
Deliver your work
  1. 17 Organize pages and choose a host
  2. 18 Read the JavaScript edition
  3. 19 Deliver the JavaScript edition offline
  4. 20 Explain and change a complete form

A server result is different from a local formula

A Python method marked @endpoint can be called from a dataRpc declaration. result_path receives the returned value. Reactive parameters can trigger a call; sampled parameters supply values when another event triggers it. A dataRpc nested in a button runs on click.

The server creates a fresh Page for each call. Fields stored on a previous Page instance are not persistent application state. Send the required arguments explicitly and put durable state in the application’s chosen service.

Make failure observable

An endpoint can return Data, not executable code. The author defines authorization and validation on the server. The hosted gallery has no identity system and does not prove authenticated access control.

Read the error path as carefully as the success path. The current RPC contract calls _onError on failure when supplied; without it the failure reaches the console. Fast repeated triggers use the documented request rule, not an unlimited queue or a blanket latest-response-wins promise. A rapid sequence can leave the displayed result behind the latest inputs; make the inputs associated with a confirmed result clear.

Your turn

Try it yourself

  1. Open Endpoint, then Call on click. Locate method, arguments and result_path.
  2. Change a sampled input without clicking; verify that this alone does not request a new result.
  3. Invoke the call, then use the lesson’s documented failure case and inspect how the error is exposed.

Check your understanding

Can a browser-side validation rule replace checking endpoint arguments on the server?

Show the answer and expected result

No. The server owns the authoritative rules and authorization. Browser validation improves interaction but callers can send requests independently. Keep local estimates and confirmed server results visibly distinguishable.

Working examples and reference