Template Tooltip Tip #1

A bit of background

Template toolkit is a powerful and mature Perl based templating engine. It is designed to be output format agnostic and used (or able to be used) with most of the Perl based Web application frameworks like Dancer, Catalyst and CGI::Application.

TT Tip #1 - Simple html attribute macro

In this tip, i'll combine using a TT macro with HTML plugin to create a simple macro to add active class to html element.

code

TT code: (put in top of template or shared TT file pulled in with PROCESS or INCLUDE)
[% USE HTML %]

[% MACRO active GET HTML.attributes( 'class' => 'active' ) %]

Usage in a template:


<ul id="navBar"> 
  <li [% active IF page.name == 'home' %]>Home</li>
  <li [% active IF page.name == 'about' %]>about</li>
  <li [% active IF page.name == 'contact' %]>contact</li>
</ul>




In this case, when page.name matches then macro will drop in class="active". Simple but much more readable then a bunch of statements like:


[% IF page.name == 'home' %]class="active"[% END %]




I'm sure there are more elegant ways to create menu bar or breadcrumbs but this is intended to give you a feel of using a TT macro.



A block with a process or include could be used but that ends up with template code like [% PROCESS active IF page.name == 'home' %] but i think the macro call is clearer with less directive line noise.



 
__END__





































Comments











Post a Comment



















Popular posts from this blog









Template Toolkit Debugging inside of Perl Dancer





















 The other day someone was asking how to enable Template Toolkit  debugging inside of Perl Dancer  in the #dancer  IRC channel, it seemed like a good time for a write up.   The template engine configuration directive supports passing through various options like start_tag  and stop_tag  as explained in Dancer::Template::TemplateToolkit  POD. And alludes to being able to pass other options.   How   To pass TT options like those found in Template::Constants , there must be a DEBUG  section in engines -> template_toolkit , usually found in config.yml .   Example Snippet    Here is an example:   A few notes     Remove leading DEBUG_  from TT constants. The option DEBUG_PLUGINS  becomes plugins .    Multiple options can be separated with a comma. Example: DEBUG: "provider,plugins" .   Be warned, some of these options can lead to tons of information :)    __END__     








Read more










BootstrapX clickover





















Birth  The last few weeks, i've been pushing Bootstrap  in various directions. Most of the time, its being hacking around Popovers. Our current design uses Popovers with forms. It provides a very nice balance between in page action and more subtle interruption to viewing the page than a modal.   Over the last few weeks, I've found a few quirks with using Popover's  trigger action of 'focus'. This works fine with forms but on Chrome and Safari 'focus' events are supported incompletely . In addition to that varied support we have a few other needs that inspired a new Bootstrap  extension. BootstrapX - Clickover .   Our requirements are:     Click button/link/icon to toggle display of popover content     Option to click 'away' from popover to close     Ability to have 'popover' autoclose after some amount of time     Option to have element inside of popover hide it   I suspect, in the future, it will need to only auto close when user's mouse








Read more










Changing Dancer::Plugin::Ajax's content type





















 Dancer does lots of great things. It has a nice clean way to define routes to handle AJAX routes using the plugin Dancer::Plugin::Ajax .    ajax routes are defined in a clear way:  ajax '/stuff' => sub {   # do work and return };    This plugin technique allows for clear way to separate between ajax and other types of actions for the same route.  ajax '/stuff' => sub {    # do ajax-y stuff here };  get '/stuff' => sub {    # handle html response };    Unfortunately, the one negative with Dancer::Plugin::Ajax  is that is assumes all responses will be XML.     A quick fix is to manually set the content type  in each ajax handler.   ajax '/stuff' => sub {    content_type('application/json');        # do work };   or add set it as a general option in your main before hook or in each prefix route handler like:  package WebApp;  hook before => sub {    if ( request->is_ajax ) {       content_type('application/json');    } }; 








Read more