v79 / caisson Goto Github PK

The AbstractController does a bit too much, particularly being dependent on thymeleaf-template-engine. Add some flexibility to this.

The client could submit a JSON string as a parameter presenting an object. We could use GSON or something to construct the model object from the JSON string.

See Ktor ContentNegotiation for inspiration.

But how would this fit with with our flow? Probably a different implementation and binding, request.bindJson<Person>()?

Given that it's possible to pass functions as parameters in Kotlin, they could perhaps be used as an alternative to @CConverter annotated parameters?

Currently, the input name in the view must match the property name in the constructor of the model class. Consider providing a way of overriding this so that the view name can be different.

Perhaps as an annotation, or an additional parameter to the bind() method. Perhaps a map?

In a web form, a person's address will typically have a number of fields (3 lines, plus town, country, postcode, etc). Rather than requiring the model class to list all of these, allow the developer to create a class which represents an entire address. Use an annotation to tell Caisson to 'bundle up' all the related fields as a single object.

data class Address(val addr1: String, val town: String //etc)
data class Person(val name: String, @CCompoundConverter(AddressConverter::class) val address: Address)

To make this work we'll have to enforce a naming scheme on the HTML form elements. Perhaps each of the address input fields will need to be prepended with the name of the constructor parameter? E.g.

<input type="text" name="address.addr1"/>
<input type="text" name="address.town"/>
<!-- etc -->

To ease testing, rewriting, etc. But what should the implementation class be called?

Create a class with some additional properties that are set during the init{} block and test these values are set during binding.