blob: 9a6e116dd183b50e9cdb2b26c65dd6b133d70bf4 (
plain) (
blame)
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
84
85
86
87
88
89
90
91
92
|
=head1 NAME
Reaction::Manual::Templates
=head1 DESCRIPTION
This is a detailed description of reaction's template system.
=head1 OVERVIEW
=head2 SKINS
=head3 Organization
Reaction's templates are organized into sets called skins. A skin is defined by
a directory containing several template files and static assets. Skins live in
directories under the C<share/skin> path in your application distribution. Each
directory and the template files within compose their own skin. Templates live
in the C<layout> directory and assets live in the C<web> directory.
=head3 Core Skins
Reaction provides prebuilt skins called C<base> and C<default>. These provide
the basic html components for a typical web application, such as forms, fields
and table list views. Skins are extensible, which means you can include all the
templates from another skin within your custom skin through a configuration
directive instead of copying template files, making your template setup easy to
maintain.
=head3 Configuration Directives
The C<share/skin/defaults.conf> file holds general application-wide skin
configuration. Each skin can be configured individually by placing a C<skin.conf>
file in it's root directory.
=over
=item * extends $skin_name
Defines C<$skin_name> as the base skin.
=back
=head2 TEMPLATES
Template files are sets of pod-like directives which define a set of layouts.
They are used for the sole purpose of describing how the data is to be layed out
at render time. Each template file contains a set of layout definitions which are
used by reaction widgets to generate the final content. Variables are defined and
populated in the widgets then passed to the layout fragments in a given template
file.
=head3 Template Directives
=over
=item * =for layout $fragment_name
Defines a layout fragment called C<$fragment_name>, everything under the
directive up to the next fragment directive is part of the definition. By default,
variables with the same name as an existing layout definition are rendered as the
equivalent layout. Widgets might interfere and select an alternate layout or
template to be rendered instead. A templates' rendering process always starts by
a layout called C<widget>.
=item * =extends $template_name
Makes the current template inherit the layout definitions in C<$template_name>.
Layouts defined in the template override the ones in the base template. The
special C<NEXT> template name specifies that inheritance should use the equivalent
template from the base skin as configured in C<skin.conf>.
=item * =widget $widget_name
Selects C<$widget_name> as the driver for the current template.
=back
=head2 LAYOUT FRAGMENTS
=head3 Scope
A layout definition creates a variable scope attached to that layout. Variables
only exist within their specific layout fragments, that is, they are scoped to
specific layouts. Overriding a layout places it in the same scope as the base layout.
=head3 Using layouts defined in base templates
The special [% call_next %] variable will be replaced by the layout in the base
template within the same scope.
=cut
|
