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 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277
|
.. _Other_services:
**************
Other Services
**************
.. _Tag_utils:
Tag utils
=========
.. index:: Tag utils
.. highlight:: ada
The child package `Utils`, see :ref:`Templates_Parser.Utils`
contains a routine to encode a Tag variable into a string and the
inverse routine that build a Tag given it's string
representation. This is useful for example, in the context of AWS to
store a Tag into a session variable. See the AWS project.
.. _XML_representation:
XML representation
==================
.. index:: XML
The child package `XML`, see :ref:`Templates_Parser.XML` contains
routines to save a `Translation_Set` into an XML document or to
create a `Translation_Set` by loading an XML document. The XML
document must conform to a specific `DTD` (see the Ada spec file).
.. _Templates2Ada:
Templates2Ada
=============
.. index:: templates2ada
`templates2ada` is a tool that will generate a set of Ada
packages from a templates file. These Ada packages can then be used in
your application to avoid hard-coded strings, and help maintain the
templates and the code synchronized.
One of its goal is to ensure that you are only setting tags that actually
exist in the template (and thus prevent, as much as possibly, typos in the
name of tags); also, when combined with other tools, to help ensure that all
tags needed by the template are properly set.
Templates2ada also has special knowledge about HTTP constructs
and will generate Ada constants for the HTTP parameters you might receive in
return. Once more the goal is to help avoid typos in the Ada code.
For instance, we will consider a simple template file, found in a local
file :file:`resources/block1.thtml`. This template contains the following simple
html code:
.. code-block:: xml
<form>
<input name="PARAM1" value="@_TAG1_@" />
<input name="PARAM2" value="@_TAG2_@" />
</form>}
When you run :file:`templates2ada` (as described in the following subsection),
the following Ada package will be generated. Note that this is only the
default output of :file:`templates2ada`, which can be fully tailored to your
needs::
package Templates.Block1 is
pragma Style_Checks (Off);
Template : constant string := "resources/block1.thtml";
Tag1 : constant String := "TAG1";
Tag2 : constant String := "TAG2";
package Http is
Param1 : constant String := "PARAM1";
Param2 : constant String := "PARAM2";
end Http;
end Templates.Block1;
`templates2ada` knows about special constructs in the template file.
Such templates are generally associated with html pages. It is possible to
specify within the template itself what the url associated with the template
is, so that it provides a convenient link between the two. Likewise, you
can also define explicitly what the possible HTTP parameters are when loading
that page. This is mostly useful when those parameters do not correspond to
some form fields within the page itself. The syntax for these two is the
following::
-- HTTP_URL(the_url): any comment you want
-- HTTP_GET(param1_name): description of the parameter
-- HTTP_GET(param2_name): description of the parameter
and that results in the following constants in the generated Ada package::
package Templates.Block1 is
URL : constant String := "the_url";
package Http is
Param1_Name : constant String := "param1_name";
Param2_Name : constant String := "param2_name";
end Http;
end Templates.Block1;
The templates parser API lets you define your own custom filters. It is
often useful for those filters to take parameters, just like the predefined
filters do. However, it is also useful for these parameters to be able to
check the value of other tags. One convention for doing this is to start the
name of the parameter with "@". See for example the example in
:ref:`User_defined_filters`. As a reminder, the template would look like:
.. code-block:: xml
<option value="foo" @_SELECTED(@SELECTED_STATUS):STATUS_@ />
The `templates2ada` tool knows about this special convention, and would
generate the following Ada package from this example::
package Templates.Block1 is
Selected_Status : constant String := "SELECTED_STATUS";
Status : constant String := "STATUS";
end Templates.Block1;
Running templates2ada
---------------------
This tool parses all the template files found in a directory, and then
generate an output file from these, based on a template file
(a default example of which is provided as :file:`templates.tads`). The
latter contains in fact two examples, depending on whether one Ada
package should be generated per template, or whether a single package
should be build. In the former case, if you are using the GNAT compiler,
you should run `gnatchop` on the resulting file. Here is an example
to run this tool for the example we described above.
.. code-block:: sh
$ rm -f src/templates/*.ads
$ templates2ada -d resources/ -o src/templates/generated -r
$ cd src/templates; gnatchop -w -q generated
$ rm -f src/templates/generated}
If, in you Ada code, you no longer use hard-coded strings but only the
constants found in the output packages, this will ensure that you are
not trying to set tags that are never used in the template.
The other check that impacts the quality of your code is to ensure that
all tags that are used by the templates are properly set. This cannot be
ensured by the compiler only, but using an external tool it is relatively
to do.
For instance, if you are using GNAT, we recommend the following additional
targets in your :file:`Makefile`:
.. code-block:: make
unset_tags:
gnat xref -u main.adb | fgrep templates-
This checks for all unused entities in files called :file:`templates-*`,
which are the files generated by :file:`templates2ada`.
:file:`templates2ada` can be used in other situations as well. For instance,
one possible use is to generate, as output, a new template file that itself
contains a series of *@@SET@@* commands. This generated file can
then be included (*@@INCLUDE@@*) in your own templates. We have used it with
some success when implementation a web server: it is often the case that hyper
links refer to other pages in the same server. We have avoided hard-coding the
URLs and the names of their HTTP GET parameters, by fetching these names from
the generated file we were talking above.
The templates parser comes with an example file, called :file:`all_urls.thtml`,
which can be used with the `-t` switch to `templates2ada`, and will
generated a template file as output. You would use it as:
.. code-block:: xml
@@INCLUDE@@ all_urls.html
<a href="@_URI_BLOCK1_@?@_HTTP_BLOCK1__PARAM1_@=12" />
and this ensures the link is valid.
:file:`templates2ada` supports a number of command line switches:
* -d <dir>
This switch specifies the directory in which the templates file are
searched for.
* -o <file>
This switch specifies the output file name
* -e <ext>
This file specifies the file name extension for template files. All
files in the directory that have this extension will be processed by
templates2ada.
* -t <tmplt>
This file specifies the template file to be used for the output file.
The templates parser comes with an example for such a file, called
:file:`templates.tads`, that you can adapt to your own needs.
* -r
Sub directories of the one specified by `-d` will also be searched.
* -v
Activate the verbose mode. This will output a warning when an http
parameter has a name made only of template parser tags, since no matching
entry can then be created for it in the output file.
Customizing templates2ada
-------------------------
As was mentioned before, the output of templates2ada is a single file that
results from parsing a template file. An example of such a file is provided
in the templates2ada distribution, as :file:`templates.tads`.
You are strongly encouraged to modify this file to adapt it to your needs,
and then use the `-t` switch to :file:`templates2ada` to make use of your
modified file.
This file contains extensive comments on how to make use, and customize, it.
This documentation is not duplicated here
.. _Templatespp:
Templatespp
===========
.. index:: templatespp
`templatespp` is a pre-processor based on the template parser. It is
generally used from scripts to process files and generate other files. One
of the possible uses, for instance, is to write the CSS (style-sheet) of a
web site as a template file (for instance :file:`mycss.tcss`), and use
template parser structures in there. This is a good way to share colors for
instance, or to name constants, as is often done in Ada code.
Here is a small example of such a CSS:
.. code-block:: css
@@SET@@ COLOR1=blue
@@SET@@ COLOR2=red
@@SET@@ LENGTH1=10
body {background:@_COLOR1_@}
div {background:@_COLOR2_@}
ul.class {background:@_COLOR1_@} /* same color as body */
ul {width:@_ADD(3):LENGTH1_@px} /* ul 3 pixels wider than li */
li {width:@_LENGTH1_@px}
Such a file would be processed with the following command line:
.. code-block:: sh
$ templatespp -o mycss.css mycss.tcss
Debug
=====
.. index:: Debug
A set of routines to help to debug the `Templates_Parser` engine,
see :ref:`Templates_Parser.Debug`. For example, `Debug.Print_Tree`
will display, to the standard output, a representation of the internal
semantic tree for a template file.
|