From my understanding, Template::Alloy::TT should be interchangable with Template Toolkit, however I am having some issues trying to swap one out with the other. Here is the config for my view file:
package maypp::View::HTML;
use strict;
use base 'Catalyst::View::TT';
__PACKAGE__->config({
INCLUDE_PATH => [
myapp->path_to( 'root', 'src' ),
myapp->path_to( 'root', 'lib' ),
],
PRE_PROCESS => 'config/main',
WRAPPER => 'site/wrapper',
ERROR => 'error.html',
TIMER => 0,
render_die => 1,
COMPILE_DIR => '/tmp/compiled_templates', #caches compiled templates
STAT_TTL => 1, #how long to cache templates before seeing if there are any changes
TEMPLATE_EXTENSION => '.html',
});
I thought that changing Catalyst::View::TT to Catalyst::View::TT::Alloy would be all I had to do to begin using Template::Alloy (this has been the procedure for me before). However, whenever I change this I do not get the correct output. Below is my wrapper file:
[% 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 "$host/site/html" + "$host/site/layout";
END;
-%]
site/html will be processed, however site/layout does not go into site/html like it does when I just use regular Template Toolkit (typically site/layout goes into [% content %] in site/html). Is there something I'm doing wrong here? I'd like to use Template::Alloy for the speed increase, but that's only if I can get it working :) Thanks for the help!
Just taking a stab in the dark, I'd say TT::Alloy might not support the multiple WRAPPER + directive. In quite a few years of TT development, I've never used it, but that's not to say it isn't popular somewhere. My experience is an app might switch between wrapper A and wrapper B based on context, but wrapping B within A? Not so much.
If you're always going to need to do that though, why not put the second WRAPPER directive inside $host/site/html.tt ?
Related
I'm currently developing a small single-page Web app using Mojolicious. The app has a Javascript frontend (using Backbone) that talks to a REST-ish API; the layout of the source is roughly:
use Mojolicious::Lite;
# ... setup code ...
get '/' => sub {
my $c = shift;
# fetch+stash data for bootstrapped collections...
$c->render('app_template');
};
get '/api_endpoint' => sub {
my $c = shift;
# fetch appropriate API data...
$c->render(json => $response);
};
# ... more API endpoints ...
app->start;
The app template uses EP, but very minimally; the only server-side template directives just insert JSON for bootstrapped collections. It's deployed via Apache as a plain CGI script. (This isn't optimal, but it's for low-traffic internal use, and more intricate server configuration is problematic in context.) Perl CGI is configured via mod_perl.
This works most of the time, but occasionally the renderer somehow gets the idea that it should cache the template and ignore changes to it. The debug records in error_log show "Rendering cached template" rather than the normal "Rendering template", and my new changes to the template stop appearing in the browser. I can't find a reliable way to stop this, though it will eventually stop on its own according to conditions I can't discern.
How can I make the app notice template changes reliably? Alternatively, how can I disable template caching completely?
How can I make the app notice template changes reliably?
This is what the morbo development server is for. Morbo wouldn't be used for your live code deployment, but for a development environment where you are continually changing your code and templates. Generally changes to live code and templates are meant to be handled by restarting the application server, or Apache in your case. (Hypnotoad has a hot-restart capability for this purpose)
Alternatively, how can I disable template caching completely?
To do this, add the following setup code (outside of routes, after use Mojolicious::Lite):
app->renderer->cache->max_keys(0);
For old answer see below.
I turned the findings of this answer into a plugin and released it on CPAN as Mojolicious::Plugin::Renderer::WithoutCache after discussing wit Grinnz on IRC, where they encouraged a release.
You can use it like this:
use Mojolicious::Lite;
plugin 'Renderer::WithoutCache';
It will create a new Cache object that does nothing, and install that globally into the renderer. That way, it doesn't need to be created every time like my initial answer below did.
In theory, this should be faster than Grinnz' approach (which is more sensible), and since you explicitly don't want to cache, you obviously want things to be as fast as possible, right? It's supposedly faster because the real Mojo::Cache would still need to go and try to set the cache, but then abort because there are no more free keys, and it also would try to look up the values from the cache every time.
I benchmarked this with both Dumbbench and Benchmark. Both of them showed negligible results. I ran them each a couple of times, but they fluctuated a lot, and it's not clear which one is faster. I included output of a run where my implementation was faster, but it still shows how minuscule the difference is.
Benchmark with Dumbbench:
use Dumbbench;
use Mojolicious::Renderer;
use Mojolicious::Controller;
use Mojolicious::Plugin::Renderer::WithoutCache::Cache;
my $controller = Mojolicious::Controller->new;
my $renderer_zero_keys = Mojolicious::Renderer->new;
$renderer_zero_keys->cache->max_keys(0);
my $renderer_nocache = Mojolicious::Renderer->new;
$renderer_nocache->cache( Mojolicious::Plugin::Renderer::WithoutCache::Cache->new );
my $bench = Dumbbench->new(
target_rel_precision => 0.005,
initial_runs => 5000,
);
$bench->add_instances(
Dumbbench::Instance::PerlSub->new(
name => 'max_keys',
code => sub {
$renderer_zero_keys->render( $controller, { text => 'foobar' } );
}
),
Dumbbench::Instance::PerlSub->new(
name => 'WithoutCache',
code => sub {
$renderer_nocache->render( $controller, { text => 'foobar' } );
}
),
);
$bench->run;
$bench->report;
__END__
max_keys: Ran 8544 iterations (3335 outliers).
max_keys: Rounded run time per iteration: 5.19018e-06 +/- 4.1e-10 (0.0%)
WithoutCache: Ran 5512 iterations (341 outliers).
WithoutCache: Rounded run time per iteration: 5.0802e-06 +/- 5.6e-09 (0.1%)
Benchmark with Benchmark:
use Benchmark 'cmpthese';
use Mojolicious::Renderer;
use Mojolicious::Controller;
use Mojolicious::Plugin::Renderer::WithoutCache::Cache;
my $controller = Mojolicious::Controller->new;
my $renderer_zero_keys = Mojolicious::Renderer->new;
$renderer_zero_keys->cache->max_keys(0);
my $renderer_nocache = Mojolicious::Renderer->new;
$renderer_nocache->cache( Mojolicious::Plugin::Renderer::WithoutCache::Cache->new );
cmpthese(
-5,
{
'max_keys' => sub {
$renderer_zero_keys->render( $controller, { text => 'foobar' } );
},
'WithoutCache' => sub {
$renderer_nocache->render( $controller, { text => 'foobar' } );
},
}
);
__END__
Rate max_keys WithoutCache
max_keys 190934/s -- -2%
WithoutCache 193846/s 2% --
I recon in a heavy load environment with lots of calls it would eventually make a difference, but that is very hard to prove. So if you don't like to think about the internals of the cache, this plugin might be useful.
Old answer:
Looking at Mojolicious::Plugin::EPRenderer I found out that there is a cache. It's a Mojo::Cache instance, which has the methods get, set and max_keys, and inherits from Mojo::Base (like probably everything in Mojolicious).
The ::EPRenderer gets a $renderer, which is a Mojolicious::Renderer. It holds the Mojo::Cache instance. I looked at $c with Data::Printer, and found out that there is a $c->app that holds all of those.
Knowing this, you can easily make your own cache class that does nothing.
package Renderer::NoCache;
use Mojo::Base -base;
sub get {}
sub set {}
sub max_keys {}
Now you stick it into $c.
package Foo;
use Mojolicious::Lite;
get '/' => sub {
my $c = shift;
$c->app->renderer->cache( Renderer::NoCache->new );
$c->render(template => 'foo', name => 'World');
};
app->start;
__DATA__
## foo.html.ep
Hello <%= $name =%>.
Now every attempt to get or set the cache simply does nothing. It will try caching, but it will never find anything.
Of course it's not great to make a new object every time. It would be better to make that object once at startup and get it into the internal permanent version of app. You have CGI, so it might not make a difference.
You could also just monkey-patch the get out of Mojo::Cache. This more hacky approach will do the same thing:
package Foo;
use Mojolicious::Lite;
*Mojo::Cache::get = sub { };
get '/' => sub {
my $c = shift;
$c->render(template => 'foo', name => 'World');
};
app->start;
But beware: we just disabled fetching from every cache in your application that uses Mojo::Cache. This might not be what you want.
Form labels and error messages are translated automatically. But strings in the view scripts are not. I have to use $this->translate("text to transfer"); in each and every phtml files.I don't want to use this $this->translate("text to transfer"); method.How can I automatically translate view scripts as in the case of forms.My code is
protected function _initTranslation() {
$langNamespace = new Zend_Session_Namespace('language_sess');
$lang = $langNamespace->lang;
$registry = Zend_Registry::getInstance();
$tr = new Zend_Translate(
array(
'adapter' => 'array',
'content' => APPLICATION_PATH . "/languages/$lang/$lang.php",
'locale' => "ar",
'scan' => Zend_Translate::LOCALE_DIRECTORY
)
);
$registry->set('Zend_Translate', $tr);
return $registry;
}
OK, to make it clear, we need to understand few things:
Zend_Translate is supposed to translate only part of your site, not related to content. That is menu items, section names, titles, etc. You might have exceptions from that rule, especially if you use Zend_Translate_Adapter_Gettext.
For content, you should use something else to provide your translation. Usually, for example if it is a static article, you get that data from DB, not the language file.
In your case, if you are ok with a little bit "machine" translation, you should use google translate engine for sites
https://translate.google.com/manager/website/
As for dropping $this->translate("text to transfer"); part, you can try to translate all data in controller, but that is rather bad advice, I would advice you to do something else. When you pass your data to view, you can loop through it and make translation for each and everystring inside:
foreach($data as $key => $string) {
$data[$key] = $tr->translate($string);
}
or something like that. This is bad approach because of few reasons. But most important is that you are not dividing your presentation from your logic, and that is why the best place for this is View.
So my summary:
Try to keep using $this->translate()
If that really does not work for you, try to use google translate engine
If that is also not good for you, try Zend_Translate_Adapter_Gettext.
Please, do not use language files for your content.
I have a Perl command-line script that I want to convert to a rich. cross-platform desktop GUI application. What's the best method to do it. I want to the internal and the logic code in Perl but the GUI should be rich web application.
I have been working on the Perl module XUL::Gui on CPAN which uses Firefox as a host platform to render cross platform gui's from Perl. All you need is Firefox installed on the target platforms. It is currently in development, but may be stable enough for your needs. Here is a brief example of how the syntax looks:
use XUL::Gui;
display Window title => 'Foo Processor',
Hbox(
(map {
my $id = $_;
CheckBox id => $id,
label => "use $id",
option => sub {shift->checked eq 'true' ? " -$id" : ()}
} qw/foo bar baz/
),
TextBox( id => 'num',
type => 'number',
option => sub {' -num ' . shift->value}
),
Button( label => 'run', oncommand => sub {
my #opts = map {$ID{$_}->option} qw/foo bar baz num/;
$ID{txt}->value = `fooproc #opts`;
}),
),
TextBox( FILL, id => 'txt' );
Since it is under development, if you have any feature requests (or find any bugs) let me know.
Also, since you are inside of Firefox, any web technologies that Firefox supports (canvas, iframes, flash...) are fully usable from Perl. For gui components, you can use any combination of HTML and XUL tags.
Mojolicious is a light but yet powerful Web framework which is particularly useful to wrap scripts into quick and well done Web apps.
We are using it extensively on the local network to let colleagues make use of the scripts we develop on our Unix boxes, whatever their platform. For simple tasks, you can even pack everything (templates and routing) in one file: check Mojolicous::Lite.
Does it need to be a rich, native-OS style GUI? Or just any old user interface? You could get something up and running very quickly with CGI::Application - it's probably the best balance between clean, maintainable code and a short learning curve. For more heavily duty work, Catalyst seems to be the weapon of choice.
If you want to make a full-featured GUI with menus and draggable dialog boxes etc. Perl is probably not the best candidate.
If by the gui should be web for cross platfrom you mean it should be written using HTML / CSS /JavaScript, one solution is to use HTTP::Server::Simple::CGI in conjunction with CGI::Application and HTML::Template. Browser::Open completes the required minimal functionality.
I am editing packages that use Moose, and I was wondering if there were a plugin for making Moose attributes show up in the Tag List.
For example, in the following code, the attribute options does not show up in Tag_List, but print_out_site does:
use Moose;
use MooseX::AttributeHelpers;
...
has 'options' => (
metaclass => 'Collection::Hash',
isa => 'HashRef[Str]',
is => 'ro',
provides => {
exists => 'exists',
get => 'get',
set => 'set',
},
);
...
sub print_out_site {
my $self = shift;
my $key = shift;
$self->fasta_out_fh->print(">", $key, "\n");
$self->fasta_out_fh->print($self->sites->{$key}, "\n");
}
Add the line
--regex-perl=/has '(.*)' => \(/\1/a,attribute,moose attributes/
to ~/.ctags and it should show up. You may need to tweak the regular expression to avoid spurious matches in other files or to accommodate different formatting for the attribute declarations in other files.
This extends ctags so that it detects another type of tag based on the regular expression when parsing perl files.
Then you need to tell the taglist plugin about the new tag type by adding this to your vimrc file:
let tlist_perl_settings='perl;c:constant;l:label;p:package;s:subroutine;a:attribute'
Geoff, I tried your code but it didn't work for me with the syntax you use. Could this be a version problem? I'm using exuberant ctags version 5.8.
I also modified the regex a bit because the quotes are optional and you might want to allow spaces (but nothing else) preceeding the 'has' keyword.
Here is what worked for me.
I created a $HOME/.ctags file (didn't have one yet, otherwise just add to it) with the following line:
--regex-perl=/^\s*has\s+['"]?([0-9a-zA-Z_]+)/\1/a,attribute/
Then added the line in .vimrc as you suggested
let tlist_perl_settings='perl;c:constant;l:label;p:package;s:subroutine;a:attribute'
Now it lists my attributes in Moose modules.
In addition, I find it useful to also have information about the parent class, roles and used modules show up in the taglist, so here is my complete $HOME/.ctags file:
--regex-perl=/^\s*has\s+['"]?([0-9a-zA-Z_]+)/\1/a,attribute/
--regex-perl=/^\s*with\s+(['"])(.+)\1/\2/r,role/
--regex-perl=/^\s*extends\s+(['"])(.+)\1/\2/e,extends/
--regex-perl=/^\s*use\s+([^ ;]+)/\1/u,use/
and this is what I have in .vimrc (you can change the order of tags in the taglist simply by changing the order in the tlist_par_settings):
let tlist_perl_settings='perl;u:use;p:package;r:role;e:extends;c:constant;a:attribute;s:subroutine;l:label'
let Tlist_Show_One_File = 1
Because of the additional content I find it useful to use the Tlist_Show_One_File option, which forces the taglist to show only the tags of the currently selected file.
To temporarily hide some of the tags you can always move the cursor to the tag name and hit "zc" (and "zo" to reopen) the fold.
I'm trying to use Class::DBI with a simple one parent -> may chidren relationships:
Data::Company->table('Companies');
Data::Company->columns(All => qw/CompanyId Name Url/);
Data::Company->has_many(offers => 'Data::Offer'=>'CompanyId'); # =>'CompanyId'
and
Data::Offer->table('Offers');
Data::Offer->columns(All => qw/OfferId CompanyId MonthlyPrice/);
Data::Offer->has_a(company => 'Data::Company'=>'CompanyId');
I try to add a new record:
my $company = Data::Company->insert({ Name => 'Test', Url => 'http://url' });
my $offer = $company->add_to_offers({ MonthlyPrice => 100 });
But I get:
Can't locate object method "add_to_offers" via package "Data::Company"
I looked at the classical Music::CD example, but I cannot figure out what I am doing wrong.
I agree with Manni, if your package declarations are in the same file, then you need to have the class with the has_a() relationship defined first. Otherwise, if they are in different source files, then the documentation states:
Class::DBI should usually be able to
do the right things, as long as all
classes inherit Class::DBI before
'use'ing any other classes.
As to the three-argument form, you are doing it properly. The third arg for has_many() is the column in the foreign class which is a foreign key to this class. That is, Offer has a CompanyId which points to Company's CompanyId.
Thank you
Well, the issue was actually not my code, but my set up. I realized that this morning after powering on my computer:
* Apache + mod_perl on the server
* SMB mount
When I made changes to several files, not all changes seems to be loaded by mod_perl. Restarting Apache solves the issue. I've actually seen this kind of issue in the past where the client and SMB server's time are out of sync.
The code above works fine with 1 file for each module.
Thank you
I really haven't got much experience with Class:DBI, but I'll give this a shot anyway:
The documentation states that: "the class with the has_a() must be defined earlier than the class with the has_many()".
I cannot find any reference to the way you are using has_a and has_many with three arguments which is always 'CompanyId' in your case.