Bill Moseley wrote:
How can you avoid setting variables?
[...]
[% BLOCK show_list %]
[%
FOREACH item = list;
"Item = [$item]\n";
END;
%]
[% END %]
You're right, that would modify "item" in the stash. I guess the
reasons that this is
On Sat, Jan 08, 2005 at 02:44:23PM -0500, Perrin Harkins wrote:
> If you're setting variables all over the place, and you don't know them
> well enough to be sure there are no collisions, use INCLUDE. I don't
> set variables in my templates, so I use PROCESS.
How can you avoid setting variables?
On Sat, 2005-01-08 at 11:22 -0800, Bill Moseley wrote:
> That's the point, I guess. How do I know if I need to prevent
> side-effects or not?
If your approach to TT is to gather your data ahead of time and pass it
in, you probably aren't setting variables, or setting so few that you
are aware of
On Fri, Jan 07, 2005 at 11:23:23AM -0500, Perrin Harkins wrote:
> On Fri, 2005-01-07 at 08:11 -0800, Bill Moseley wrote:
> I'm not sure I'm following, but the difference between INCLUDE and
> PROCESS is that INCLUDE prevents the specific side-effect of changing
> data in the stash and is therefore
Perrin Harkins wrote:
On Tue, 2005-01-04 at 00:14 +, Tony Bowden wrote:
On Mon, Jan 03, 2005 at 06:21:14PM -0500, Perrin Harkins wrote:
I structure my web applications so that common code can be added to all
requests in a central place (some kind of common "setup" hook). I
usually put
Simon Matthews wrote:
:
:
[a buncha cool stuff]
:
:
Well, I was going to jump in and offer all my opinions, but Simon just
beat me to it. Everything he said, I agree with.
I want localization by default, especially if the "performance penalty"
is on the same order as making copies of subroutine
Andy Wardley wrote:
Rather than copying the entire variable stash each time we need to
create a localised variable scope (e.g. INCLUDE), TT3 creates a new,
empty variable stash with a parent link pointing upwards to the stash
of the calling context.
When a variable is first accessed, the stas
On Fri, 2005-01-07 at 16:53 +, Simon Matthews wrote:
> I still think that changing the default behaviour will cause untold
> mayhem for the vast number of people who have been using INCLUDE in
> the past.
I seriously doubt that, since only people who set variables in their
templates AND step o
Title: RE: [Templates] TT in callback
> -Original Message-
> I'm not sure I'm following, but the difference between
> INCLUDE and PROCESS is that INCLUDE prevents the specific
> side-effect of changing data in the stash and is therefore
> slower. If you d
On Fri, 2005-01-07 at 08:11 -0800, Bill Moseley wrote:
> Is the issue about side-effects? My data comes in from a $t->process
> hash or from a single template where I "PROCESS defaultvars.tt" in a
> common wrapper or PRE_PROCESS. It's rare that I PROCESS a template
> for side-effect of setting so
On Fri, Jan 07, 2005 at 09:02:58AM -0500, Perrin Harkins wrote:
> I think people do not read the whole doc (they would not be missing the
> localisation in INCLUDE if they did) but rather go looking for something
> called "include" and stop when they find it.
Actually, I started out using PROCESS
On Fri, 2005-01-07 at 10:39 +, Harry Jackson wrote:
> Would you then alias INCLUDE to PROCESS?
Yes.
> You know a lot more about the work involved than me but for backwards
> compatibility but would it not be easier to make INCLUDE_FAST an alias
> to PROCESS.
I think people do not read the
Perrin Harkins wrote:
On Thu, 2005-01-06 at 11:08 +, Andy Wardley wrote:
I must admit it worries me slightly that I come down 90% in favour of one
approach and you're swung 99.9% the other way. Assuming the efficiency
problem goes away in TT3, is your position that non-localising is the
corr
On Thu, Jan 06, 2005 at 03:50:33PM +, Andy Wardley wrote:
> But aside from that, do I take it you're also in favour of the "all variables
> are global unless explicitly scoped local" approach?
I'm not sure. Probably not. The opposite sounds better to me, but I
don't really see all the issues
On Thu, 2005-01-06 at 22:32 +0200, Octavian Rasnita wrote:
> I don't know, maybe Cache-Cache requires a C compiler...
It doesn't for the Cache::FileCache subclass that my plugin uses. I
have never tried any of this stuff on Win32 though. My plugin doesn't
do very much, so you could always just u
I have tried installing Template::Plugin::Cache under Windows, but without
success.
CPAN gave an error telling that "test" is not a valid command or file name
(probably when trying make test).
So I went in the .cpan directory and I have tried to manually compile the
Cache-Cache module which is req
On Thu, 6 Jan 2005, Simon Matthews wrote:
> So for my vote, INCLUDE localises, PROCESS doesn't.
>
> That way things will transfer from TT2 to TT3 far easier.
That would be consistent between versions, but I believe Perrin's original
point (correct me if I'm wrong Perrin) was that the current nam
On Thu, 2005-01-06 at 11:08 +, Andy Wardley wrote:
> I must admit it worries me slightly that I come down 90% in favour of one
> approach and you're swung 99.9% the other way. Assuming the efficiency
> problem goes away in TT3, is your position that non-localising is the
> correct behaviour
On Thu, 2005-01-06 at 09:29 +0200, Octavian Rasnita wrote:
> Ok, I think that I will need to create a program that will save the final
> HTML page, and each time the program is accessed with a browser, it will
> check if the saved html page is new enough, and if it is, it will get and
> present it,
Title: RE: [Templates] TT in callback
> But aside from that, do I take it you're also in favour of
> the "all variables
> are global unless explicitly scoped local" approach?
>
> A
>
As we seem to be taking votes, if there is no (minimal) performa
Tony Bowden wrote:
> No they don't.
Strictly speaking, yes, you're right. But I was thinking more in terms of
generally accepted good structured or OO programming practice. One usually
declares my/local variables within a subroutine (or instance variables within
an object), saving global vari
> Perl subroutines keep parameters and variables local by default
No they don't.
You have to explicitly tell them to do so.
$foo = 10;
do_stuff();
print "foo is now $foo\n";
sub do_stuff {
$foo = 12;
}
or even:
@foo = 1 .. 10;
Perrin Harkins wrote:
> All I ask is that you name the fast non-localizing way that 99.9% of the
> world should be using "INCLUDE" and name the localizing way something
> else. People constantly use the wrong one because of the names and
> don't even realize it.
Hi Perrin,
Yes, I agree that the
"
To: "Octavian Rasnita" <[EMAIL PROTECTED]>
Cc: "Perrin Harkins" <[EMAIL PROTECTED]>; "Larry Leszczynski"
<[EMAIL PROTECTED]>;
Sent: Wednesday, January 05, 2005 9:14 PM
Subject: Re: TT Caching (Was: Re: [Templates] TT in callback)
> &g
Jason Gottshall wrote:
I seem to find reasons to use INCLUDE a little more frequently. For
example, if I use PROCESS in this situation, my default variable is
useless:
bar.tt:
===
First: [% PROCESS foo.tt size = 3 %]
Second: [% PROCESS foo.tt size = 12 %]
Third: [% PROCESS foo.tt %]
Actually
Perrin wrote:
>
> On Wed, 2005-01-05 at 11:26 +, Andy Wardley wrote:
> > That's another item from the "seemed like a great idea at
> the time" list
> > that is fixed in TT3. :-)
>
> All I ask is that you name the fast non-localizing way that
> 99.9% of the world should be using "INCLUDE"
On Wed, 2005-01-05 at 10:52 -0800, Len Weisberg wrote:
> I have another question about caching in this sort of environment:
>
> I would like to be able to indicate for a particular run of process():
> a) do NOT use the compilation cached in the COMPILE_DIR
> b) but DO store the results of this
> "Octavian" == Octavian Rasnita <[EMAIL PROTECTED]> writes:
Octavian> ...regarding caching...
Octavian> If I have a site which is updated dayly, once per each day, it would
be
Octavian> helpful if TT could create a cache of the final result (the html
page) like
Octavian> proxy server do, an
Octavian Rasnita wrote:
...regarding caching...
If I have a site which is updated dayly, once per each day, it would be
helpful if TT could create a cache of the final result (the html page) like
proxy server do, and recreate again the web page after each new day...
Is something like this possible
- Original Message -
From: "Perrin Harkins" <[EMAIL PROTECTED]>
To: "Larry Leszczynski" <[EMAIL PROTECTED]>
Cc:
Sent: Wednesday, January 05, 2005 8:07 PM
Subject: Re: TT Caching (Was: Re: [Templates] TT in callback)
__
On 2005-01-05 10:07 AM, Perrin Harkins wrote:
> On Wed, 2005-01-05 at 12:18 -0500, Larry Leszczynski wrote:
>
> >> Is there any way to take advantage of the cache in a non-persistent e.g.
> >> non-webserver) environment? Maybe along the lines of serializing the
> >> template object and reading it
On Wed, 2005-01-05 at 18:13 +, Simon Wistow wrote:
> On Wed, Jan 05, 2005 at 01:07:14PM -0500, Perrin Harkins said:
> > No, but the COMPILE_DIR option means that at least the "compile to perl"
> > step will be skipped. If there was a way to store compiled perl code
> > and load it faster, it w
Hi Perrin -
> > Is there any way to take advantage of the cache in a non-persistent (e.g.
> > non-webserver) environment? Maybe along the lines of serializing the
> > template object and reading it back later?
>
> No, but the COMPILE_DIR option means that at least the "compile to perl"
> step wil
On Wed, Jan 05, 2005 at 01:07:14PM -0500, Perrin Harkins said:
> No, but the COMPILE_DIR option means that at least the "compile to perl"
> step will be skipped. If there was a way to store compiled perl code
> and load it faster, it would be used in all kinds of modules.
B::Bytecode?
"This comp
On Wed, 2005-01-05 at 12:18 -0500, Larry Leszczynski wrote:
> Is there any way to take advantage of the cache in a non-persistent (e.g.
> non-webserver) environment? Maybe along the lines of serializing the
> template object and reading it back later?
No, but the COMPILE_DIR option means that at
On Wed, 5 Jan 2005, Perrin Harkins wrote:
> I can't stress enough that this really makes a difference. By creating
> a new object every time, you are breaking TT's caching system. It has
> to compile the perl code for each template used on every single request.
> It's almost as bad as the diffe
On Wed, 2005-01-05 at 11:26 +, Andy Wardley wrote:
> That's another item from the "seemed like a great idea at the time" list
> that is fixed in TT3. :-)
All I ask is that you name the fast non-localizing way that 99.9% of the
world should be using "INCLUDE" and name the localizing way some
Perrin Harkins wrote:
> It would work fine, but there is a performance penalty for using INCLUDE
> which many people are not aware of. INCLUDE makes a complete copy of
> the Stash in order to give the included template a private copy of the
> data. Most people don't need this, so INCLUDE is just
Perrin Harkins wrote:
> Caching the object is very important. It makes a big difference in
> performance. Please change that.
>
> (Hmm... maybe CPAN needs some kind of Template::Toolkit::Singleton
> module to make this more obvious to people.)
For TT3 I'm thinking that the Template module shoul
On Wed, 05 Jan 2005 00:18:54 -0500, Perrin Harkins <[EMAIL PROTECTED]> wrote:
> Store it in an application-specific namespace then, so that each app has
> a separate one but all are cached.
I like the sound of that... How about a configuration something like this:
sub cgiapp_init {
my $self =
On Tue, 2005-01-04 at 21:39 -0500, Cees Hek wrote:
> It might boost performance, but it can also have unexpected
> consequences. If I am running several different applications on the
> same mod_perl server, then the TT singleton is going to be configured
> by the first app that is executed, even t
On Tue, 04 Jan 2005 18:54:53 -0500, Perrin Harkins <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-01-04 at 17:18 -0500, Cees Hek wrote:
> > This works well for me. But then again, I am not caching these
> > objects across requests
>
> Caching the object is very important. It makes a big difference in
On Tue, 2005-01-04 at 17:18 -0500, Cees Hek wrote:
> I usually set the INCLUDE_PATH on a per class basis, so I haven't
> found a need for it. Do you have any ideas on how to cleanly
> implement that?
The mail I pointed to showed a couple of options. You can also put a
code ref or object into the
On Tue, 04 Jan 2005 14:55:59 -0500, Perrin Harkins <[EMAIL PROTECTED]> wrote:
> On Mon, 2005-01-03 at 21:38 -0500, Cees Hek wrote:
> > I don't know exactly how Perrin does this, but I thought it might be a
> > good time for me to mention CGI::Application::Plugin::TT which is a
> > Template Toolkit
On Mon, 2005-01-03 at 21:38 -0500, Cees Hek wrote:
> I don't know exactly how Perrin does this, but I thought it might be a
> good time for me to mention CGI::Application::Plugin::TT which is a
> Template Toolkit plugin for CGI::Application. It does pretty much
> what Perrin is describing above (i
On Tue, 2005-01-04 at 00:14 +, Tony Bowden wrote:
> On Mon, Jan 03, 2005 at 06:21:14PM -0500, Perrin Harkins wrote:
> > I structure my web applications so that common code can be added to all
> > requests in a central place (some kind of common "setup" hook). I
> > usually put my $tt->process
On Tue, 2005-01-04 at 09:46 -0500, Sean T Allen wrote:
> Michael Peters wrote:
> > Why do you say not to use INCLUDE? After seeing that I did a quick
> > google but didn't see anything. I'll keep looking though...
> >
>
> Probably because in this case, include wouldnt work... as the toolbar
> ne
Michael Peters wrote:
Perrin Harkins wrote:
On Mon, 2005-01-03 at 17:39 -0500, Arshavir Grigorian wrote:
The stash contents should be passed to all templates that you call
already. That's the default behavior.
I am not sure what you mean. Could you please explain this a little
more?
My assumpti
Perrin Harkins wrote:
On Mon, 2005-01-03 at 17:39 -0500, Arshavir Grigorian wrote:
The stash contents should be passed to all templates that you call
already. That's the default behavior.
I am not sure what you mean. Could you please explain this a little more?
My assumption is that you have tem
> "Cees" == Cees Hek <[EMAIL PROTECTED]> writes:
Cees>
http://search.cpan.org/~ceeshek/CGI-Application-Plugin-TT-0.04/lib/CGI/Application/Plugin/TT.pm
And, CGI::Prototype also defaults to Template Toolkit, with some nice
connections there.
--
Randal L. Schwartz - Stonehenge Consulting Serv
On Tue, 4 Jan 2005 00:14:00 +, Tony Bowden <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 03, 2005 at 06:21:14PM -0500, Perrin Harkins wrote:
> > I structure my web applications so that common code can be added to all
> > requests in a central place (some kind of common "setup" hook). I
> > usually
On Mon, Jan 03, 2005 at 06:21:14PM -0500, Perrin Harkins wrote:
> I structure my web applications so that common code can be added to all
> requests in a central place (some kind of common "setup" hook). I
> usually put my $tt->process inside of some wrapper function as well,
> since I want it to
On Mon, 2005-01-03 at 17:39 -0500, Arshavir Grigorian wrote:
> >The stash contents should be passed to all templates that you call
> >already. That's the default behavior.
> >
> >
> I am not sure what you mean. Could you please explain this a little more?
My assumption is that you have template
Perrin Harkins wrote:
On Mon, 2005-01-03 at 16:55 -0500, Arshavir Grigorian wrote:
I thought about that, but it would mean passing this data to every page,
then code every page to relay it to the toolbar library template on each
include.
The stash contents should be passed to all template
On Mon, 2005-01-03 at 16:55 -0500, Arshavir Grigorian wrote:
> I thought about that, but it would mean passing this data to every page,
> then code every page to relay it to the toolbar library template on each
> include.
The stash contents should be passed to all templates that you call
already
Perrin Harkins wrote:
On Mon, 2005-01-03 at 14:13 -0500, Arshavir Grigorian wrote:
I have a package subroutine that requires an Apache request object and
will return a list of privileges (based on a session id stored in
pnotes). So I am wondering whether I should be using TT's Plugin
interfac
On Mon, 2005-01-03 at 14:13 -0500, Arshavir Grigorian wrote:
> I have a package subroutine that requires an Apache request object and
> will return a list of privileges (based on a session id stored in
> pnotes). So I am wondering whether I should be using TT's Plugin
> interface to make this su
57 matches
Mail list logo
