Is there a way to detect what browser you are using through template toolkit? For example I can achieve what I want to do using jQuery but thought it would be useful to know how to do it in template toolkit if possible?
Jquery
<script>
jQuery(window).load(function(){
if ( (jQuery.browser.msie && jQuery.browser.version < 9.0) )
{
jQuery('body').addClass('old-ie');
}
});
</script>
In template toolkit I want to do something like the below but can't see this in the documentation anywhere?
<body
[% IF browser.msie && browser.version < 9.0 %]
class="old-ie"
[% ELSE %]
[% END %]
>
I'm not aware of a TT plug-in for this, but it's trivial to add a line or two to your back-end application to make the information available to the template. For example, if your app is Catalyst based, you would add something like this to your main program:
__PACKAGE__->apply_request_class_roles(qw/
Catalyst::TraitFor::Request::BrowserDetect
/);
... and in your 'auto' handler, introduce a line such as (untested):
$c->stash(browser => $c->req->browser);
... or just use this is your template:
[%- SET browser = c.req.browser;
SET old_ie = 'class="old-ie"'
IF browser.windows && browser.ie && browser.public_major < 9.0;
-%]
and then include old_ie wherever it's required in your template.
See Catalyst::TraitFor::Request::BrowserDetect and HTTP::BrowserDetect for more info and options. I'm sure there are similar plugins/methods for Dancer, Mojolicious etc.
You could do that through the HTTP request headers. You didn't mention what was calling TT, but if you're using Catalyst, you could use Catalyst::TraitFor::Request::BrowserDetect, and then pass a variable to TT to say what kind of browser was requesting the page.
Related
I have run some scripts to generate storage capacity report and configuration settings report using perl. I would like send this report to my mail id in html using perl.
Please note that I am new to perl programming.
Your question is very vague, so it's hard to be of much help. This might point you in the right direction though.
You basically have three tasks here.
Parse your report into data structures.
Use your data structures to generate an HTML document.
Send the HTML document by email.
I can't really help with step 1 as I know nothing about your report. If you have your file in CSV format, then Text:CSV will be useful to you. It's worth pointing out that if you're generating this report, then you could generate it in a format that is easier to parse - JSON, for example.
For step 2, I'd recommend a templating engine. I'd use the Template Toolkit, but other options are available. The idea is that you create a template file that contains all of your HTML with "tags" where you want your variable data to go. On a simple level it might look something like this:
<html>
<head><title>Some Title</title></head>
<body>
<h1>Some Title</h1>
<p>Blah...</p>
<table>
[% FOREACH row IN data -%]
<tr><td>[% row.value %]</td><td>[% row.another_value %]</td></tr>
[% END -%]
<table>
</body>
</html>
Assuming that's in a file called email.tt and you have your data in an array of hashes called #data, then you'd process the template like this:
use Template;
#data = ({
value => 'something',
another_value => 'something else',
}, {
value => 'something',
another_value => 'something else',
});
my $tt = Template->new;
$tt->process('email.tt', { data => \#data }, \$email_body)
or die $tt->error;
That will give you your expanded HTML in $email_body. And that brings us to step 3.
I recommend Email::Stuffer for sending email.
use Email::Stuffer;
Email::Stuffer->from ('you#example.com')
->to ('someone_else#example.com')
->html_body($email_body)
->send;
I am using underscore.js templates, and have certain if conditions embedded within template. I would like to use coffeescript within the template.
<% if (app.user.get("id") != -1 or app.user.get("product")?.name != "Foo") {%>
do-stuff
<% } %>
Above won't work, I have to use javascript instead of coffee.
Is there a way to get this done, other than using any further third party libraries like haml-coffee?
Nope if you're working in that environment it'll have to be native js. You could however, do some of the work in a coffee script file that returns an html template instead.
I have a relatively large legacy Perl/CGI/DBI web application which generates HTML on-the-fly piece by piece. We are reworking the HTML being produced, to come in to compliance with HTML 5 / CSS 3. This would be a good time to move to some sort of template system. We do NOT want to engage in a complete rewrite, and thus do NOT want to migrate to a framework such as Catalyst.
I'm thinking that Perl Template Toolkit might be our lowest-impact means. I'm re-reading the venerable Badger Book to study up on feasibility.
My question is this. Has anyone here migrated "old school" Perl web code to Template Toolkit? Are there any tricks you can share for minimizing the rewrite/rework needed? We have not 100% decided on Template Toolkit, either. If there is an alternative which we should consider?
What problem, specifically, are we trying to solve? We're generating invalid HTML and need to clean that up. Since we're cleaning, we want to produce fully-valid HTML 5 and, to the extent practicable, valid CSS3 and Javascript. We use jQuery, jQuery UI widgets, and AJAX via jQuery. We have typical Page Controller MVC architecture except no View layer as such. We'd like to go to some sort of template system but don't want to rewrite everything (or much of anything!) to migrate.
Thank You!
Ed Barnard, Cannon Falls MN
Here's what I've found, as I've moved my practice from CGI.pm to TT, and what I've also learned along the way using HTML::Mason, HTML::Template, Text::Template, and working with ERB and HAML in Rails.
The more logic you have in in your displays, especially if it is written in a display specific language, the less fun you're going to have.
I've come to prefer HAML for the reduction in size of the contents of my templates [ In HAML, closing tags are implied by indentation ]
Perform as much of the logic to compute the various dynamic bits of the page before you drop into the template, in the application's native language. [ call view methods, before engaging in rendering ].
In relation to (3), by using methods, instead of inline display/rendering logic, you can make your templates declarative, so while you might be performing logic in the middle of the render, your templates don't have a bunch of IF/THEN/ELSE logic causing clutter.
Let's imagine a reasonably small, contrived web page made up of a header, and footer and a body. Let's assume that the footer is completely static, the body changes every time a new page loads, but the header only changes when a user logs in/out.
You can imagine the header containing code like this:
<header>
[% IF $user.is_logged_in THEN %]
Hello [% $user.name %] - Log Out
[% ELSE %]
Please Log In
[% END %]
</header>
But you're better off in the long term doing this in header.tt:
<header>
[% user_info($user) |html %]
</header>
and this in View::Helpers::Header.pm:
sub user_info {
my $user = shift;
if ($user->{is_logged_in} ) {
return "Hello $user->{name} - " . logout_link($user->{id});
}
else {
return "Please " . login_link();
}
}
sub logout_link {
my $userid = shift;
return qq(Log Out)
}
You can, of course, implement the view helpers in TT rather than pure Perl, and I don't have any kind of numbers for you, but if you've done all of your logic in Perl already, you can refactor the Perl into modules (if it isn't there already), instead of re-coding them in TT.
As part of your test suite, consider an HTML validator like HTML::Lint or HTML::Tidy.
I'm writing a plugin which should add HTML to the page's head area (inludeJS to be exact). Something like this should work:
page.includeJS {
tx_myplugin_pi1 = EXT:my_plugin/pi1/tx_myplugin_fe_scripts.js
}
The problem with that is that I have to assume that "page" would be the universal name used for the page object I want to work with. Since the name of this variable can be anything I would like to do this in a more intelligent way than this.
Is there a way to determine the name of the current PAGE cObject I'm working with?
cu
Roman
You can find out the default PAGE object of the current page using this snippet:
$setup = $GLOBALS['TSFE']->tmpl->setup;
foreach(array_keys($setup) as $key){
if(substr($key, -1) == '.'){
if($setup[substr($key,0,-1)] === 'PAGE' && intval($setup[$key]['typeNum']) === 0){
print substr($key,0,-1) .' is the default PAGE object';
}
}
}
But this won't help you to add the Javascript in the frontend, as the typoscript is being parsed already at that point.
If you want to add the javascript just for your extension I would recommend using:
$GLOBALS['TSFE']->additionalHeaderData['tx_yourextension_plugin'] = '<script type="text/javascript" src="' . t3lib_extMgm::siteRelPath('my_plugin') . 'pi1/tx_myplugin_fe_scripts.js"></script>';
(this wouldn't be merged with the other JS files though)
Actually there is no such way in plain TypoScript. As most installations are using page as keyword - especially those which are under your control - it is really fine to use it.
If you are writing an extension, you can put that into the documentation as a small hint!
Is there a way to disabling a WRAPPER that was set in new(\%config), through either the template, or a temporary override with parse()? I want to have a single default WRAPPER (that I'll use for 99.9% of my templates), but exclude a few.
I'm doing this all through Catalyst::View::TT just like the example in the configuration synopsis, except I don't want the WRAPPER to apply to all of my templates.
Edit the wrapper, to include a conditional like:
[% IF no_wrapper OR template.no_wrapper %] [% content %] [% ELSE %]
top;
[% content %]
bottom;
[% END %]
This allows me to disable the wrapper either (1) inside of template, or (2) from the stash.
[%- META no_wrapper = 1 -%]
$c->stash->{no_wrapper} = 1
META var ...; is a directive that makes var accessible through the template hash as template.var
source: http://wiki.catalystframework.org/wiki/gettingstarted/howtos/template_wrappers
Define exceptions in site/wrapper itself, and btw there are exceptions defined there already.
[% IF template.name.match('\.(css|js|txt)');
debug("Passing page through as text: $template.name");
content;
ELSE;
debug("Applying HTML page layout wrappers to $template.name\n");
content WRAPPER site/html + site/layout;
END;
-%]
I stumbled into the same problem, and created a more generalized solution that allows for dynamic switching of layouts, or to have no layout at all. See here:
More than one layout/wrapper with Dancer and Template::Toolkit