Schemas

Schemas define the structure of your form and its validations: they provide the means for KForm to create, manipulate, and validate values of your form.

Let’s look at an example, imagine that you want to build a form that allows users to purchase bus tickets. Assume that your form is represented by the following Kotlin data classes:

Model of a form for purchasing bus tickets

data class BusTripForm(var email: String, var passengers: List<Passenger>)

data class Passenger(var name: String, var age: Int?)

As we can see, this form is represented by custom classes containing strings, (nullable) integers, and lists, all written in standard Kotlin code not at all related to KForm.

So, how can KForm reason about these seemingly arbitrary types of data? This is what schemas are for: they offer KForm insight on the structure and types of your data (as well as how to validate it).

The following example shows how the schema of our bus ticket purchasing form can be defined (for now without any validations):

Schema of a form for purchasing bus tickets

val BusTripFormSchema = ClassSchema {
    BusTripForm::email { StringSchema() }
    BusTripForm::passengers {
        ListSchema {
            ClassSchema {
                Passenger::name { StringSchema() }
                Passenger::age { NullableSchema { IntSchema() } }
            }
        }
    }
}

This definition enables KForm to understand that our form is represented by a class BusTripForm containing two fields: email and passengers, of types String and List<Passenger> respectively.

Different schema types

Create your own schema type