Smarty

[boots]

Monte: can't wait to see how it develops.

Andre:

[Wom.bat]

monte: PLEASE give us something like {nocache}-blocks, too. It's often that I couldn't do something with a non-cached function, because it's not always exactly the same thing I want to put out or whatever... see my posting above on this for a little example... always throwing the non-cached parts into extra templates and then let these templates be returned by non-cached functions doesn't make sense, I may well use inserts for that, too

[boots]

One thing that I like about this patch is that it allows non-cached block functions which is not at possible in the current Smarty, even with insert-type syntax.

[mohrt]

A {nocache}{/nocache} block would simply be a block function registered as non-cached.

Monte

[boots]

[Wom.bat]

D'Oh, forgive me, Monte, I should use my own brain more often

[andre]

[Wom.bat]

I guess this is the best idea - just write the PHP code to the cache. {insert}s are sloooooooooooooooow

[andre]

Soo... back again

The only problem I see with the above two posting is the following:

Cache files can be stored everywhere. It depends on your cache file handler. So including with include() function is not always possible. So this raises another question:

1) Templates can be loaded from anywhere (because they don't need to be included)
2) Compiled templates needs to resist in the file system (because they get included)
3) Cached templates can resist anywhere again

I think a upcoming Smarty version will also allow compiled templates to be stored anywhere. So question to Monte / Messju: Is this planned? If yes, how do you think you can implement this? So how do you "include" the compiled template if its located in a DB for example?
Exactly this (yet unknown) way I would prefer for including the cached templates with PHP in them. I know the idea Messju (Monte?) had about separating the executable code from the cached template and store it in a separate file. This way the separated code can be easily included again which gives performance. BUT WHAT if you don't want Smarty to create files in your filesystem? If you want it to store EVERYTHING within your database?

So perhaps we could create a Smarty method here to execute the script code located in a string (e.g. a file on your hard drive or a string stored within a DB). This method should be so flexible it can execute a code on your harddrive by including it (use "include()" function) or to eval() it if it comes from another source. This way the execution / inclusion of a source (say template, compiled template or cached template) is fully transparent to the Smarty class.

Back to the point of discussion :
If you store your cached templates onto your file system it will be included by "include()" which is fast and is even more accelerated by PHPAccelerator. If your cached templates lie outside of your file system into a database for example the output gets evaled with "eval()" which is quite slow compared to the first method.

Hope you understand what I wanted to say. Please ignore the typos because I'm drunk at the moment but most people say I am most productive if I am drunk (it's 11 p.m here )

[andre]

Short addition and idea:

1) Remove all cache file handling from Smarty
2) Create a separate cache handling class which is included in Smarty package which is nothing more than a "custom" (but standardized) cache handler function
3) Like custom resource types these custom cache handlers do everything Smarty needs. So there need to be methods for getting cache creation time, methods to retrieve cache infos like lifetime etc., a method to get the cached content, etc. (Everything the current custom cache handlers need to do too already)
4) Add a new method: execute() which evals the code of the cache. For the standard cache handler this is a simple include(). For a cache handler which is using DB access this will be a eval() perhaps.

So it would be even more transparent to Smarty. I saw that the default cache handling is hardcoded within the Smarty class. Changing this could perhaps solve the problems?!

____
Now it's time for TV ... 'till tomorrow

[mohrt]

Yes, abstracting the cache handling from Smarty into a plugin is the right idea. This goes back to the rendering "pipeline" that has been discussed in the mailing lists in the past. This will require some fundamental changes to the engine (such as cache files being included() instead of interpreted), but all in all will make the core even tighter and more flexible. There is more than just caching that can be abstracted too.

The tricky part is getting abstraction without an added overhead (basically dealing with wrappered function calls). The main obstacle is you cannot add methods to an already instantiated object. Look at how the compiler is abstracted, this is basically a hack but it works, it gets the compiling code out of the main object and reduces its size by more than half. When PHP5 rolls around that might be different, but until that can be required (long way off), we make use of what we've got.

Monte

[boots]

Ramblings:

[boots]

On caches:

One thing I find confusing is talking about "cache" directory and "compile" directory. They are both file caches, they just contain different data and within smarty have different precedences and rebuilding rules. But to a cache handler, they should be the same animal (the rules can be plugged via a driver, I bet). I almost wish the names were "compile cache" and "output cache".

A single orderly interface to deal with caches would be neat. Especially if it allowed n-cache types and allowed sharing of id's across types. That way other libraries that use caches can be managed by the single class and can have its cache data group tagged with smarty cache data.

Sorry if I am repeating old discussions that I am unaware of or saying to many obvious things--kinda why I was looking for a roadmap

4c.

[messju]

sorry, i'm really busy here. i won't be able to get hands on this till the weekend, i'm afraid.

anyway: i like the idea of taking the cache-handling out of the core, though it won't be easy. personally, i don't like the idea of taking the compiled templates out of the filesystem and i am also not attracted by the idea of emitting the php-code directly in the cached template. but that's just my superficial feeling at the moment, so not problematic at all.

i have also some code which i didn't touch for a few weeks (just cvs upd to keep it in sync with head). AFAIR it has some similarities to andre's approach like the nocache parameter. btw: i'd vote for calling the parameter $cacheable instead of $cached. (just a thought)

i have done different versions (all buggy of course) all around the same core changes in the compiler. one version uses eval to evaluate the non-cached parts. one version generates a cache-file that is a valid includable php-file, like the compiled template and one version writes a second php-file next to the compiled-tpl, that contains the non-cached parts as function-definitions.
the last one should be able to share the functions of one compile-id by all it's associated cache_ids, it's the one i like most, although it implies a third file in addition to compiled-tpl and cached-tpl and maybe the additional logic eats up the good idea.

i am eager to benchmark these and andre's one to get a feeling, how the different approaches behave performance-wise. till now i only tested if they produce reasonable output at all i know there won't be no optimal solution. some approach may be better with a lot of non-cached parts, another may be better used with a few bigger non-cached parts etc.
but i think it is important to become a slight idea how much (and in which) direction they differ.

andre: if you have testcode for your non-cached function you wish to share, tell me.

i have to get busy now...

greetings
messju

[andre]