Serving a web page built from a Web Page template
A Web Page template needs to be mapped to a path via a controller, or route in order to be accessible from a browser. So to expose a Web Page template you have two options:
- Create a web controller written in either Gloop or Groovy; or
- Let Martini configure a route for your template through Gloop template properties.
Configuring a route for your Web Page template
The simplest way to bind a Web Page template to a path is by configuring a route. A Web Page template's route can be configured via the Web Page template editor; particularly in the Route tab of the Properties view.
Once a route for a template is configured, the template will be available under the base path /app
.
For example, given the route /todo
for a template, the template will be accessible at the URL
http://{host}:{port}/app/todo
.
To configure a route for your template, here are the steps you need to follow:
- Open the Web Page template you want to expose.
- Click the table icon in the toolbar to show the Properties view. The Properties view, by default, will be displayed on the right side of your screen.
- In the Properties view, open the Route tab.
- Select which HTTP method(s) your web content will be served under.
Typically,
GET
is used when the client only requests data; andPOST
is for forms, for clients submitting data. - If you've selected
POST
, you may now set the request body for your mapping. The body can be any of the template's inputs; configured using the Body Parameter dropdown. - Enter the URL path you want the template to be mapped to.
This is the URL where clients would be accessing your web page.
In the URL, you can also specify path parameters by wrapping them in braces
{}
. Martini will map your path parameter to any identically named Gloop template input property (except for properties that are models or objects). - Save the changes by pressing . Your route will be exposed shortly after your instance has finished registering your template's route. This typically only takes a few seconds.
Exposing your template using a Gloop controller
The simplest way to create a controller in Gloop is by creating a service
with an ad hoc REST endpoint, and a string output property named $gloopView
.
$gloopView
lets Martini know that instead of a RESTful response, the controller would be returning a view.
$gloopView
must be assigned the namespace of the Gloop template, suffixed with .gtpl
.
For example, if your template is located at code/com/torocloud/todo/Index.gtpl
; then your view's namespace is
com.torocloud.todo.Index
. Therefore in your code, $gloopView
's value must be set to
com.torocloud.todo.Index.gtpl
.
If your service controller returns output properties other than $gloopView
, Martini will do its best to
map those properties to your Gloop template's input(s). This way, models can be passed from the controller to the view.
Consider the following example:
Greeting
is a template with a string input property name
, whose value is displayed in a <p>
tag when rendered.
Greeting
is exposed through GreetingController
using the $gloopView
property (not shown in the image).
GreetingController
also takes a string input name
, whose value is taken from the path variable {name}
.
If you visit the path /api/hello/world
in your browser with this configuration, Greeting
will be rendered as:
1 2 3 4 5 6 7 |
|
Exposing your template using a Groovy controller
To create a Groovy web controller, you'll have to use Spring annotations. Consider the following example:
This controller maps HTTP requests to /hello/{name}
to the sayHello()
method.
It adds a name
attribute, whose value is derived from the path parameter name
,
to the model which will be passed to the view.
And lastly, it configures a view named com.torocloud.hello.Greeting.gtpl
for said mapping.
If you visit the path /api/hello/world
in your browser with this configuration, Greeting
will be rendered as:
1 2 3 4 5 6 7 |
|
While powerful, developing in Groovy can be complex. Good development practices should be consistently implemented in order to avoid unmanageable code.