Yancy::Help::Config - How to configure Yancy
version 1.011
use Mojolicious::Lite; plugin Yancy => { backend => 'pg://localhost/myapp', read_schema => 1, collections => { users => { title => 'Users', description => 'The authorized user accounts', }, }, };
This document describes all of the configuration available for Yancy.
When using the Yancy Mojolicious plugin, these values are given as a hash reference argument to the plugin. See "CONFIGURATION" in Mojolicious::Plugin::Yancy for some plugin-specific configuration values.
When using the Yancy standalone mode, these values are defined in a yancy.conf file which is parsed as a Perl hash reference. See Yancy::Help::Standalone for more information about running the standalone app.
yancy.conf
The backend URL defines what database to use and how to connect to it. Each backend has its own format of URL, and some examples are shown below. See your backend's documentation for more information.
backend
# Backend URL backend => 'pg://user@example.com/mydb', # Backend hash backend => { Pg => { dsn => 'dbi:Pg:dbname', username => 'fry', password => 'b3nd3r1sgr34t', }, }
# Backend URL backend => 'mysql://user@localhost/mydb', # Backend hash backend => { Mysql => { dsn => 'dbi:mysql:mydb', username => 'fry', password => 'b3nd3r1sgr34t', }, }
# Backend URL backend => 'sqlite:filename.db', # Backend hash backend => { Sqlite => { dsn => 'sqlite:data.db', }, }
# Backend URL backend => 'dbic://My::Schema/dbi:SQLite:file.db', # Backend arrayref (passed to Schema->connect() method) backend => { Dbic => [ 'My::Schema', 'dbi:SQLite:mysql.db', undef, undef, { PrintError => 1 }, ], }
The collections data structure defines what data is in the database. Each key in this structure refers to the name of a collection, and the value describe the fields for items inside the collection.
collections
Each backend may define a collection differently. For a relational database like Postgres or MySQL, a collection is a table, and the fields are columns. For an ORM like DBIx::Class, the collections are ResultSet objects. For a document store like MongoDB, the collections are collections. See your backend's documentation for more information.
Collections are configured using JSON Schema. The JSON Schema defines what fields (properties) an item has, and what type of data those field have. The JSON Schema also can define constraints like required fields or validate strings with regular expressions. The schema can also contain metadata like a title, description, and even an example value. For more information on what can be defined, see the docs on JSON Schema.
title
description
example
For a collection named people that has 3 fields (an integer id and two strings, name and email), a minimal JSON schema will look like this:
people
id
name
email
collections => { people => { properties => { id => { type => 'integer', readOnly => 1, }, name => { type => 'string', }, email => { type => 'string', }, }, }, },
Instead of (or in addition to) defining collections yourself, you can tell Yancy to read your database to try to determine your collection configuration. See read_schema for more information.
Yancy generates input elements based on the type, and format of the object's properties.
type
format
type => "boolean" - A Yes/No field
type => "boolean"
type => "integer" - A number field (<input type="number" >)
type => "integer"
<input type="number" >
type => "number" - A number field (<input type="number" >)
type => "number"
type => "string", format => "date" - A date field (<input type="date">)
type => "string", format => "date"
<input type="date">
type => "string", format => "date-time" - A date/time field (<input type="datetime-local">)
type => "string", format => "date-time"
<input type="datetime-local">
type => "string", format => "email" - A e-mail address (<input type="email">)
type => "string", format => "email"
<input type="email">
type => "string", format => "url" - A URL input (<input type="url">)
type => "string", format => "url"
<input type="url">
type => "string", format => "tel" - A telephone number (<input type="tel">)
type => "string", format => "tel"
<input type="tel">
type => "string", format => "textarea" - A multiline text field (<textarea>)
type => "string", format => "textarea"
<textarea>
JSON schemas allow specifying multiple types for a field using an array. If a field has multiple types, the generated form will use the first type to decide what kind of field to display.
Fields with an enum property will be translated to <select> elements.
enum
<select>
Other schema attributes will be translated as necessary to the HTML input fields:
title will be used to label the input field
description will be placed near the input field to explain it
readOnly will set the input field as read-only
readOnly
pattern for string fields, a string that can be used as a regex, like pattern => '^foo-\d+$'.
pattern
pattern => '^foo-\d+$'
minimum for numeric fields, the minimum value
minimum
maximum for numeric fields, the maximum value
maximum
minLength for string fields, the minimum length
minLength
maxLength for string fields, the maximum length
maxLength
A Markdown editor can be enabled by using type => "string", format => "markdown". The Markdown can then be saved as HTML in another field by adding x-html-field => $field_name.
type => "string", format => "markdown"
x-html-field => $field_name
JSON Schema allows marking properties as required using the required property, which must be an array of property names.
required
collections => { people => { required => [ 'name', 'email' ], properties => { id => { type => 'integer', readOnly => 1, }, name => { type => 'string', }, email => { type => 'string', }, }, }, },
Required values will be marked as such in the HTML.
If a value can be null (undef in Perl terms) in addition to its declared type (string, integer, etc...), you must add it to the type field by using an array of types:
null
undef
string
integer
collections => { people => { required => [ 'name' ], properties => { id => { type => 'integer', readOnly => 1, }, name => { type => 'string', # Required and must be a string }, email => { type => [ 'string', 'null' ], # Can be null }, }, }, },
If you don't do this, and still include the field in an object, you will get an error: Expected string - Got null.. The correct way to fix this error is to add null as an option for the field's type.
Expected string - Got null.
Setting an example value makes it easier to add new data. When a user tries to add a new item, Yancy will fill in the data from the example key of the collection. This key holds an example object using fake data. As an example of our people collection:
people => { example => { name => 'Philip J. Fry', email => 'fry@aol.com', }, properties => { ... }, },
There are some extended fields you can add to your collection definition to control how it is treated by Yancy.
A friendly title for the collection
A description of the collection. Markdown will be parsed into HTML.
You can use the trim and unindent functions from Mojo::Util to allow indenting your collection description:
trim
unindent
use Mojolicious::Lite; use Mojo::Util qw( unindent trim ); plugin Yancy => { collections => { employees => { description => unindent( trim q{ The employees of Planet Express. * [View the employee health plan](/decapod-life) * [Latest Good News](/news) } ), }, }, };
If this is true, the collection will be hidden from the list in the Yancy web app. This does not prevent using the API to edit this data.
Ignore this collection: Do not add it to the API, do not show it in the rich editing form. This is for collections that should not be edited from the Yancy form or the Yancy API.
This allows for removing collections when using "read_schema".
This key sets the name of the collection's ID field to use to uniquely identify individual items. By default, Yancy assumes the ID field is named id. If your collection uses some other identifier (e-mail address or username for example), you should set this configuration key.
people => { 'x-id-field' => 'email', properties => { ... }, },
This field can be any unique identifier, but it will be the ID that Yancy uses for all of its operations.
This key should be an array of columns to display on the list view, in order. This helps put useful information on the list page.
people => { 'x-list-columns' => [ 'name', 'email' ], properties => { ... }, },
Instead of field names, columns can also be made out of templates using a hash with title and template keys. Inside the template key, use fields from the row with {field}, like so:
template
{field}
people => { 'x-list-columns' => [ { title => "Person", template => '{name} <{email}>' }, ], },
A URL to view the collection in the application. Will be shown as a button in the editor.
A URL to view the items in the collection. Will be shown as an icon next to the item row. Add data from the row in the url using {field}, like so:
# /people/1 /people/{id} # /user/preaction /user/{username}
There are some extended fields you can add to a field configuration to control how it is treated by Yancy.
A friendly title for the field
A description of the field. Markdown will be parsed into HTML.
If true, thie field will be hidden from the rich editing form. This is for collections that you want to use from the API but do not want to edit from the Yancy application.
Set the order of the fields in the edit form by assigning a number to the x-order property. Fields in the form are be sorted by their x-order, and then by their name (alphabetically). Fields that do not have x-order set will be sorted after fields that do.
x-order
This key is an array of filter names to run on the field when setting or creating an item. Filters can allow for hashing passwords, for example. Filters are added by plugins or during configuration of Mojolicious::Plugin::Yancy. See "yancy.filter.add" in Mojolicious::Plugin::Yancy for how to create a filter in your app.
There are additional configuration keys to alter how Yancy works.
read_schema
When this is set, Yancy will read your backend to see what collections you have available. Any collections and fields that you do not configure will be assigned default configuration from your database schema. You can use the configuration to override information that Yancy gets incorrect, or to set information that Yancy can't (like the title and description of collections and properties).
NOTE: This exposes all the data in your schema to Yancy's API, which allows anyone to edit the data. If you do not want anyone to edit the data, use the plugin's route configuration to add authentication to Yancy.
api_controller
To customize how Yancy responds to API requests with data, you can create a custom controller and set the class name here. For details how to create a custom API controller, see Yancy::Controller::Yancy::API.
Yancy, Mojolicious::Plugin::Yancy
Doug Bell <preaction@cpan.org>
This software is copyright (c) 2018 by Doug Bell.
This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.
To install Yancy, copy and paste the appropriate command in to your terminal.
cpanm
cpanm Yancy
CPAN shell
perl -MCPAN -e shell install Yancy
For more information on module installation, please visit the detailed CPAN module installation guide.