I recently started using Template Toolkit (TT) after being a long time HTML::Template (H::T) user. I had started using Catalyst and a discussion on the mailing list convinced me to try TT. I found several TT benefits that have made a big difference in cleaning up my code. I use TT as the View for Catalyst. I've used HTML::Template with Catalyst, CGI::Application and stand-alone.
H::T has a philosophy of strong separation of layout and logic. Using TT with a web framework allows a philosophy of separation of business logic and presentation logic. For a site with complex presentation logic, the H::T approach leads to placing that logic in the application code. TT's functionality allows presentation logic to be put in the template, and business logic in the application code. My application code has become much more streamlined and easier to follow using TT with Catalyst.
The primary benefits I've found so far are:
(1) Complex Perl datatype support: Perl data structures and objects can be delivered directly to the template without reformatting to the template language. In a MVC framework, it also allows data from the Model to be sent to the View without reformatting. This information is accessed by TT's "unified dot notation" and eliminates a lot of code and improves readability.
(2) Rich template language: Display logic can be moved into the template and separated from the business logic. Wrapper, complex if/elsif conditionals and join have been useful so far.
(3) Framework context object access: When used with a framework such as Catalyst or CGI::Application, TT templates can access context data and methods thus eliminating code in the application whose sole purpose would be to take variables and insert them into parameters. With Catalyst, TT can access plugins such as FormValidator, FormValidator::Simple, Prototype, etc. With CGI::Application, TT can access the HTMLPrototype plugin using CGI::Application::Plugin::TT. The ability of TT to access the framework context object is a big incentive to use framework wrappers for CPAN modules instead of using the modules directly.
These features have all contributed to simplifying the application code which is important in a large application. I'm still fond of HTML::Template for it's simplicity and easy installation but for large/complex web applications, Template Toolkit provides substantial maintainability benefits.
NOTE: This review compares TT with the base H::T distribution. To address concerns with H::T, there are some variations of and extensions to H::T that provide additional functionality, some of which is similar to what TT offers. TT-like access to nested method calls and hashrefs can be provided by either: HTML::Template::Plugin::Dot or HTML::Template::Compiled. At the moment, H::T::Plugin::Dot requires H::T::Pluggable while H::T::Compiled uses a slightly different API and lists it's object rendering feature as experimental. Context object access will be available using H::T::Plugin::Dot via CGI::Application::Plugin::HTDot in the future. Expression support is available via HTML::Template::Expr. Additional versions include H::T::Pro and Matt Robertson's version with enhanced functionality available at: members.optusnet.com.au/~mathew/html_... . I appreciate the efforts to enhance H::T, however I hope the base H::T distribution can incorporate some of the more popular features so the code will not become fractured requiring people to use code that is less widely used, tested, and patched. With multiple distributions, it's also uncertain if any change to one will propagate to others in a timely manner.
This module works great with Catalyst and Catalyst::Plugin::FormValidator::Simple. The simple interface makes it easy to use when creating custom named errors for more precise error messages. The POD provides easy-to-understand documentation for integration with TT.
This is a great module for validating forms with Catalyst, especially when custom constraints are needed. The flexible interface allows you to set multiple named errors easily for more precise error messages. The FormValidator::Simple POD provides easy-to-understand documentation for integration with TT.
A nice enhancement would be the ability to define custom Catalyst constraint methods in the profile but I'm not sure if this is a good idea. I tried using Catalyst::Plugin::FormValidator which does allow custom constraint methods in the profile but had issues getting custom constraint methods to work in a Catalyst environment.
Catalyst brings some serious web development mojo to Perl. For a long time I stuck with Perl because of CPAN but thought other languages provided better frameworks and were leaving Perl behind. No more with Catalyst.
Catalyst is a MVC web framework designed to handle all the common web application functionality and let you spend your time on the application as opposed to the plumbing. To achieve its goal it combines abstraction with a logical architecture to produce a robust, plug-and-play, component-based platform for developing web applications.
This is supported by several key benefits:
(1) MVC architecture: Perhaps most among Perl frameworks, Catalyst supports a strong separation of concerns according to the MVC method. This allows large web applications to be built while keeping the code organized and easy to understand.
(2) Object/component management: Large Perl web applications tend to grow into a collection of many parts whether those parts are objects, functional modules, or simply a large collection of scripts. Often it is up to the developer to decide how to connect the parts. Catalyst combines multiple-inheritance, component auto-discovery, URL-dispatching, and view forwarding to do this for you. Catalyst handles a lot of basic design and architecture that other frameworks require saving a huge amount of time both in initial development and maintenance when someone has to understand and modify the code.
(3) Engine abstraction: Support for CGI, multiple persistent Perl environments and multiple web servers is built-in. Often upgrading from mod_cgi to mod_perl requires a certain amount of pain. And while converting a web application from mod_perl 1.9x to 2.x (incl. apreq, etc.) is manageable, why bother when Catalyst will use both transparently? Need more than Apache/mod_perl? Catalyst will let your growing requirements use the lighttpd and Zeus web servers. Abstracting away engine support will save a lot of time when planning for growth and when making the transition.
(4) Component abstraction: For common functionality, Catalyst attempts to provide a unified API to multiple CPAN modules in the areas of ORM, templating systems, session management, authentication etc. This removes a lot of the effort from switching from one option to another as often you only need to learn the Catalyst API making it easy to change component options and come up to speed on a project that has made different component choices.
(5) Flexibility / TIMTOWTDI: Unlike some frameworks, if any part of the system doesn't suit your needs, there are other options available or you can make your own. While Catalyst recommends a certain configuration and component selection, you are free to customize it to fit the projects and/or developers particular needs. In certian situations, being able to choose one way of doing things over the other may dramatically increase productivity.
Some caveats: Catalyst can run on mod_cgi but a persistent environment is recommended for production. Documentation can be improved.
Already, I can't imagine building a complex Perl web app any other way. Thanks and kudos to the Catalyst team!