GOLF(2gg)

GOLF(2gg) — the call-handler page, bestie edition 💖

okay so you're in the GOLF manual, section 2gg (Development), and this is the glow-up of call-handler. sit down, hydrate, let's get into it ✨

---

🌸 NAME 🌸

call-handler — (service-processing program-flow)

---

🎀 PURPOSE 🎀

Call another handler within the same process. that's it, that's the whole vibe. one process, one little handler-to-handler phone call 💅

---

✨ SYNTAX ✨

call-handler <request path> [ return-value  <return value> ]

---

🦋 DESCRIPTION 🦋

So here's the tea: call-handler calls another handler, inside the same request, inside the same process. You can call literally any handler within the same application. and when we say "calling a handler," we mean executing it solely within the context of the top handler currently running — so no before-handler and no after-handler will run for the called handler. none. zero. not invited to the party 🙈

<request path> is the request path served by the handler you're calling. It can be a string variable or a constant — your call, bestie.

Wanna pass params between the caller and the callee handlers? Use set-param and get-param. that's the group chat DM channel between them 💌

You can grab a <return value> from the called handler <request path> by using the return-value clause. and if you're wondering how to return a number value from a <request path> handler, go read return-handler — it's the whole tutorial, no cap.

oh and this part is iconic: call-handler uses the same high-performance hash table that a request uses to route requests by name. so if <request path> is a constant string, the hash table lookup happens only once for the life of the process, and all subsequent calls just use a cached address of the request handler. fast. efficient. main character energy 🔥

---

💜 EXAMPLES 💜

The following example demonstrates calling a call-handler twice, and also using its output inline in the caller. An input parameter is passed to it, and an output obtained:

Copy to file "callsub.golf":

    %% /callsub public
        //
        // First call to call-handler
        //
        // Set input for call-handler
        set-param inp = "some string"
        (( s
        call-handler "/sub/service"
        ))
        // Get output from call-handler
        get-param out type string
        @<<print-out s>> with output [<<print-out out>>]

        //
        // Second call to call-handler
        //
        // Set input for call-handler called as inline code
        set-param inp = "new string"
        (( s
        @Output: <<call-handler "/sub/service">>
        ))
        // Get output from call-handler
        get-param out type string
        @<<print-out s>> with output [<<print-out out>>]
    %%

And in "sub/service.golf" file (meaning file "service.golf" in subdirectory "sub"):

    %% /sub/service private
        @This is sub!
        get-param inp
        (( out
        @got input: <<print-out inp>>
        ))
        set-param out = out
    %%

Create and build an application:

    gg -k subhandler
    gg -q

Run it:

    gg -r --req="/callsub" --exec --silent-header

The output:

    This is sub! with output [got input: some string]
    Output: This is sub! with output [got input: new string]

---

🌈 SEE ALSO 🌈

Program flow — go read these too, they're all part of the lore:

• break-loop
• call-handler
• code-blocks
• continue-loop
• do-once
• exit-handler
• if-defined
• if-true
• quit-process
• return-handler
• start-loop

Service processing:

• after-handler
• before-handler
• begin-handler
• call-handler

See all documentation 💖

---

okay that's the page!! this one's from $VERSION and dated $DATE — signed, sealed, slayed, and filed under GOLF(2gg) 🫶✨