Defining A Type
#
Furo types are organized in packages, you can have as many types per package as you want.
Lets do a simple example in µSpec and spec and see what the resulting proto will be.
Define the type in µSpec
#
The following example is a complete type definition. You can use every type from your specs and installed
dependencies. You do not need to import them. The imports are resolved and checked by Furo when you translate your µSecs to standard specs with the command furo muSpec2spec
.
File: muspec/auth/auth.types.yaml
1
2
3
4
5
|
- type: 'auth.Credentials #Credentials type for login.'
fields:
password: '* string:1 #The password.'
username: '* string:2 #The username or email, or something to identify.'
second_factor: 'string:3 #A second factor like TOTP.'
|
It helps a lot to know the anatomy of a µSpec,
read more here
Define the type in standard spec
#
The standard specs have a much higher information density then the µSpecs.
Furo will fill out as much as possible with good defaults by using the .furo
configuration file.
It helps a lot to know the anatomy of a standard spec,
read more here
File: specs/auth/Credentials.type.spec
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
|
name: Credentials
type: Credentials
description: Credentials type for login.
__proto:
package: auth
targetfile: auth.proto
imports: []
options:
go_package: github.com/foo/bar/dist/pb/auth;authpb
java_multiple_files: "true"
java_outer_classname: AuthProto
java_package: com.auth
fields:
password:
type: string
description: The password.
__proto:
number: 1
oneof: ""
__ui:
component: ""
flags: []
noinit: false
noskip: false
meta:
default: ""
hint: ""
label: auth.Credentials.password.label
options:
flags: []
list: []
readonly: false
repeated: false
typespecific: null
constraints:
required:
is: "true"
message: password is required
username:
type: string
description: The username or email, or something to identify.
__proto:
number: 2
oneof: ""
__ui:
component: ""
flags: []
noinit: false
noskip: false
meta:
default: ""
hint: ""
label: label.Credentials.username
options:
flags: []
list: []
readonly: false
repeated: false
typespecific: null
constraints:
required:
is: "true"
message: username is required
second_factor:
type: string
description: A second factor like TOTP.
__proto:
number: 3
oneof: ""
__ui:
component: ""
flags: []
noinit: false
noskip: false
meta:
default: ""
hint: ""
label: label.auth.Credentials.second_factor
options: null
readonly: false
repeated: false
typespecific: null
constraints: {}
|
Resulting proto from the type definition
#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
// Code generated by furo-proto-gen. DO NOT EDIT.
syntax = "proto3";
package auth;
option go_package = "github.com/foo/bar/dist/pb/auth;authpb";
option java_multiple_files = true;
option java_outer_classname = "AuthProto";
option java_package = "com.auth";
// Credentials type for login.
message Credentials {
// The password.
string password = 1;
// The username or email, or something to identify.
string username = 2;
// A second factor like TOTP.
string second_factor = 3;
}
|
Specifying Field Types
#
Use the
scalar value types from proto3 or types
that you have defined or installed.
You have always to write the package name (package.Type) too , when you plan to use the furo client framework, even when you are on the same file.
Packages and Name Resolution
#
Like in protobuf the type
name resolution works like C++: first the innermost scope is searched, then the next-innermost, and so on, with each package considered to be “inner” to its parent package. A leading ‘.’ (for example, .foo.bar.Baz) means to start from the outermost scope instead.
Field IDs
#
The field IDs are also used for the generated protos as
field numbers.
Reserved Fields
#
There is no concept for reserved fields at the moment.