File: call-handler.2gg

package info (click to toggle)
golf 601.4.41-1
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid
  • size: 2,824 kB
  • sloc: ansic: 20,020; sh: 1,171; makefile: 292
file content (136 lines) | stat: -rw-r--r-- 3,062 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
.TH GOLF 2gg $VERSION $DATE Development Tools
.SH NAME
call-handler \-  (service-processing
program-flow)
.SH PURPOSE
Call another handler within the same process.

.SH SYNTAX

.RS 4
.EX

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

.EE
.RE

.SH DESCRIPTION
Calls another handler within the same request in the same process. You can call any handler within the same application. "Calling a handler" means executing it solely within the context of the top handler currently running; no before-handler or after-handler will execute for the called handler.

<request path> is the \fBrequest\fP path served by the handler being called. It can be a string variable or a constant.

Use \fBset-param\fP and \fBget-param\fP to pass parameters between the caller and callee handlers.

You can obtain a <return value> from the called handler <request path> by using "return-value" clause. See \fBreturn-handler\fP on how to return a number value from <request path> handler.

call-handler uses the same high-performance hash table used by a \fBrequest\fP to route requests by name; if <request path> is a constant string, then a hash table lookup is performed only once for the life of the process and all subsequent calls use a cached address of the request handler.

.SH EXAMPLES
The following example demonstrate 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":

.RS 4
.EX

%% /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>>]
%%

.EE
.RE

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

.RS 4
.EX

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

.EE
.RE

Create and build an application:

.RS 4
.EX

gg -k subhandler
gg -q

.EE
.RE

Run it:

.RS 4
.EX

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

.EE
.RE

The output:

.RS 4
.EX

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

.EE
.RE

.SH SEE ALSO
 Program flow

\fBbreak-loop\fP  
\fBcall-handler\fP  
\fBcode-blocks\fP  
\fBcontinue-loop\fP  
\fBdo-once\fP  
\fBexit-handler\fP  
\fBif-defined\fP  
\fBif-true\fP  
\fBquit-process\fP  
\fBreturn-handler\fP  
\fBstart-loop\fP   
 Service processing

\fBafter-handler\fP  
\fBbefore-handler\fP  
\fBbegin-handler\fP  
\fBcall-handler\fP   
See all 
\fBdocumentation\fP