Gantry Book Errata

Version 1.1

In Chapter 7, on pages 74-75 the Job Ad example uses the traditional CGI approach to multi-valued selects, namely it splits them on the null character. As of Gantry 3.51 multi-valued selects come in as either a scalar (if there is only one) or as an array reference (if there are more than one).

Version 1.0

In chapter 2:

The first footnote should refer to Bigtop::ScriptHelp::Style::KickStart, whose perldoc describes the new kickstart syntax.

On page 9 and in Table 2.1, the book says there are five tabs in tentmaker. There are four tabs in tentmaker now. The App Config tab has become a regular block on the App Body tab.

For at least some versions of mysql, app.db is not a legal database name. If you have that problem, replace app.db with app_db and add the -n app_db flag when you start app.server.

In chapter 3:

The first footnote should explain that after you move app.cgi to the cgi-bin directory for your Apache server, you need to make sure that Apache can read and write in your build directory, that it can read and write app.db, and read the conf files in the docs sub-directory of the build directory. Further, if you move app.db or change database engines, you will need to change the CGI config block in the bigtop file and regenerate. You need to work on the dbconn variable where the database connection information is. Change it to suit your system's paths.

In Moving to Mod Perl, the advice to switch engines on the Bigtop Config tab is probably unnecessary if you use mod_perl 2. The defaults now target that and make CGI work in the app.cgi script. Likewise, the advice to check and uncheck backends is probably not necessary since CGI and mod_perl no co-exists peacefully.

On page 22, when told to click on the App Config tab, scroll back up to the config block while staying on the App Body tab.

The section on moving to Gantry::Conf is largely moot now. It's not wrong about what needs to happen to make use of Gantry::Conf. But, Gantry::Conf is now the default behavior for all new apps built from the command line with tentmaker or bigtop. (If you build with bigtop -c file.bigtop, file.bigtop will govern how conf is setup. In particular, if you download the code for the book and use the bigtop files from it, conf will be setup according to those bigtop files' contents. In that case, the advice in section 3.2 might help a lot.)

The only thing you might want to do is remove the conffile value, so it will default to /etc/gantry.conf. If you do that, put this in /etc/gantry.conf:

    Include /etc/gantry.d/*.conf

Then create the /etc/gantry.d directory and copy (or symbolically link) docs/AppName.gantry.conf to the /etc/gantry.d directory.

You can achieve the effects of sub-section 3.2.1 using named config blocks in your bigtop file now. But, you can also do it manually as explained in that sub-section.

In chapter 4:

The book asserts that you must prefix URLs with POST: in order for Gantry tests to treat their query strings as form parameters. Actually, query strings are always treated that way during testing. But, labeling with POST is still good documentation.

In chapters 6 and 7:

There are new versions of all the large code examples in the new book code tar ball. These are slightly different than the ones in the book.

Note that form methods are no longer generated in CRUD stubs. Look for them in GEN modules instead. To modify them, you can override the GEN code with a method of the same name in the stub. Then it is useful to dispatch to SUPER (as is shown for do_main) and use Gantry::Utils::FormMunger to achieve desired form changes.

In chapter 8:

Form methods are no longer generated in the stub module for CRUD controllers.

There is a new util module to help you munge forms, see Gantry::Utils::FormMunger. You don't need to use it, but it sure is nice. You can use it with both AutoCRUD and CRUD.

In chapter 9:

There is a new plugin callback phase: post_engine_init which fires just after engine_init returns and before uri, location, path_info, and method are called. The Cache plugin uses it.

In chapter 13:

Tentmaker's App Config tab is gone. The config table it managed is now the first config block on the App Body (the one with no name or called base). You can create additional blocks. These lead to additional Gantry::Conf instances you can switch between. See for example, the help message from a current app.server. If your have an unnamed block and another called postgresql, you can start app.server to access the named block like this:

    ./app.server -t postgresql

All of that is optional, but default apps (those built from the command line) now have a CGI block with hard coded paths.

In chapter 14:

You can now have multiple config blocks (see the note for chapter 13 for one possible use). The first one does not need a name (but could be called base). The others can have any name you like. These create additional Gantry::Conf instances. Again, you don't need multiple config blocks, but they can be useful for dev, qual, prod progressions and the like.