Hey guys, For weeks I was going along fine, then all the sudden, in all of my templates, whenever I use an XHTML entity ( © < > etc), I get a capital "A" with a caret (Â) preceding every single entity. I don't remember changing my template dispatcher, but I did upgrade my Petal version. Was there anything that could have been changed in Petal to cause this? -Warren
On Mon 18-Jul-2005 at 09:07 -0500, Warren Smith wrote: > > For weeks I was going along fine, then all the sudden, in all of my > templates, whenever I use an XHTML entity ( © < > etc), > I get a capital "A" with a caret (Â) preceding every single entity. I > don't remember changing my template dispatcher, but I did upgrade my > Petal version. Was there anything that could have been changed in Petal > to cause this? Sounds like utf-8 being labelled as latin1. Does rolling back to the previous version of Petal fix the problem? -- -- Bruno
I'm the author of CGI::Application::Plugin::AnyTemplate, which tries to
create a unified template API for CGI::Application. Currently it
supports HTML::Template, Template::Toolkit and Petal.
Where possible, I've tried to smooth over the API differences between
the modules so that the user can switch templating systems without
changing application code.
One feature that I haven't been able to emulate in Petal is the ability
to create a template from a string instead of a file.
my $string = <<EOF;
...some template text...
EOF
# HTML::Template
my $template = HTML::Template->new(
scalarref => \$string,
);
# Template::Toolkit
my $template = Template->new;
$template->process(\$string);
There doesn't seem to be a way to do this in Petal, short of writing the
string to a temporary file and then passing the file to Petal.
Is this something that could be supported in Petal some day?
(Continue reading)Hi Michael, I agree this would be a good feature to have. We are hoping to, in the near future, create an I18N preprocessor, which will pre-process and populate any i18n:translate tags which do not contain i18n:name tags. The idea is to cache per-language versions of each template (maybe using Cache::FileCache) which can be read into Petal for normal compilation and processing. So being able to construct a template from a string could be useful. One thought though - how will Petal cache the complied version of a template created from a string? Perhaps some sort of 'cache key' could be passed to the constructor? ~mark Michael Graham wrote: >I'm the author of CGI::Application::Plugin::AnyTemplate, which tries to >create a unified template API for CGI::Application. Currently it >supports HTML::Template, Template::Toolkit and Petal. > >Where possible, I've tried to smooth over the API differences between >the modules so that the user can switch templating systems without >changing application code. > >One feature that I haven't been able to emulate in Petal is the ability >to create a template from a string instead of a file. > > my $string = <<EOF;(Continue reading)
On Thu 21-Jul-2005 at 09:42 +0100, Mark Holland wrote: > > I agree this would be a good feature to have. We are hoping to, in > the near future, create an I18N preprocessor, which will > pre-process and populate any i18n:translate tags which do not > contain i18n:name tags. Are you using I18NFool? This is the framework we built for internationalising Petal templates: http://search.cpan.org/dist/I18NFool/ (yeah stupid name, I know) The Petal::I18N documentation is a little out-of date in this respect: http://search.cpan.org/dist/Petal/lib/Petal/I18N.pm > The idea is to cache per-language versions of each template (maybe > using Cache::FileCache) which can be read into Petal for normal > compilation and processing. So being able to construct a template > from a string could be useful. Petal already caches templates seperately for each language. This was buggy until recently, but it should be ok now. > One thought though - how will Petal cache the complied version of > a template created from a string? Perhaps some sort of 'cache key' > could be passed to the constructor?(Continue reading)
Michael Graham wrote: >I'm the author of CGI::Application::Plugin::AnyTemplate, which tries to >create a unified template API for CGI::Application. Currently it >supports HTML::Template, Template::Toolkit and Petal. > >Where possible, I've tried to smooth over the API differences between >the modules so that the user can switch templating systems without >changing application code. > >One feature that I haven't been able to emulate in Petal is the ability >to create a template from a string instead of a file. > >[...] > >There doesn't seem to be a way to do this in Petal, short of writing the >string to a temporary file and then passing the file to Petal. > >Is this something that could be supported in Petal some day? > >It's a useful feature for authors who want to bundle a default set of >generic templates in the .pm file of their application. > > This feature would also be very useful for applications that need to generate templates dynamically. g >Michael(Continue reading)
> One thought though - how will Petal cache the complied version of a > template created from a string? Perhaps some sort of 'cache key' could > be passed to the constructor? That's a good question. I initially tried making a Petal subclass that didn't need a filename, but I got foiled by all the file caching stuff. Since we can make strings look like filehandles, would a filehandle work just as well? As for a cache key, maybe you could use "SCALAR(0x813cd9c)" or whatever the stringified version of the scalarref's address is? It would mean that to change the template you'd have to pass in a new string, not just change the existing buffer. Michael -- Michael Graham <magog@...>
If you just replace the filename with "SCALAR(0x813cd9c)" then you'll
also get an md5 hash appended which would mean that changing the
string would be enough. However using "SCALAR(0x813cd9c)" would mean
that it would not persist between runs.
So to be clever you could do something like
$filename = "//strings/".md5sum("some salt".$string);
the // ensures the filename won't collide with a real file. The md5sum
and the "some salt" means that we have 2 md5sum in the cached filename
making it even less likely to have an md5 hash collision but the
filename for a string will be the same every time we run the program,
F
On 7/21/05, Michael Graham <magog@...> wrote:
>
> > One thought though - how will Petal cache the complied version of a
> > template created from a string? Perhaps some sort of 'cache key' could
> > be passed to the constructor?
>
> That's a good question. I initially tried making a Petal subclass that
> didn't need a filename, but I got foiled by all the file caching stuff.
>
> Since we can make strings look like filehandles, would a filehandle work
> just as well?
>
> As for a cache key, maybe you could use "SCALAR(0x813cd9c)" or whatever
> the stringified version of the scalarref's address is? It would mean
(Continue reading)
RSS Feed3 | |
|---|---|
3 | |
1 | |
2 | |
2 | |
1 | |
1 | |
5 | |
1 | |
2 | |
8 | |
11 | |
3 | |
10 | |
19 | |
10 | |
8 | |
8 | |
5 | |
8 | |
12 | |
18 | |
25 | |
8 | |
9 | |
11 | |
12 | |
22 | |
30 | |
66 | |
17 | |
15 | |
3 | |
9 | |
36 | |
10 | |
12 | |
19 | |
21 | |
9 | |
18 |
