Re: [SMARTY-DEV] Re: config vars are now static

boots wrote:

--- Monte Ohrt <monte@ispi.net> wrote:

1. Literal names in the config_file 'file' parameter are now required: no more dynamically selected configurations.

Yes, see my notes in my previous e-mail to Thomas Seifert, it should solve this problem. I guess it is a decision which would be faster: including a static template (one file stat), or building the config data array statically in the template and accessing them dynamically. Hmm, maybe #2 would be easier, quicker and better BC. It's actually almost the same as the original setup, except instead of storing the config file data in a cache file, it would be buried directly in the template where the config_load happens.

I have to check, but I think I previously looked at both ways and I think that is the order I tried things, too :) 1) store data to a cache file, include cache file, and then finally, 2) embed the results of a var_export of the config_vars into the compiled template so that the compiled template had instant access to them at runtime. I consider the latter as preferable, at least for BC. I think it also addresses the second issue I raised...

2. All templates are now required to explicitly do a config_load to have access to the configuration values.

You always have to load config file values into a template to be able to access them. Whether you use {config_load} directly in the

template

or the config_load() API to load them, the data gets compiled statically in either case, but the difference is that {config_load} won't be called again after compiletime, whereas config_load() may needlessly load config file data every invocation (unless you take steps manually to avoid that.) Also in both methods, templates will get recompiled upon a change to a config file value.

hmmm. Considering just the {config_load} behaviour, it used to be that if template A nested template B and template A did a {config_load} resulting in the var #CONFIG# being available to template A, then #CONFIG# would also be available to template B at runtime even when template B does not explicitly call {config_load}. The present CVS requires that template B use {config_load} to access #CONFIG#. Still, option #2 above should take care of this as well, I think, as the config_var array would be loaded by template A (in this case) meaning that template B would see the necessary config vars. Speaking of doing filestat's, I was wondering what the trade-offs would be of collecting file information at startup (and perhaps persisting it to disk) for the main paths (config dir, template dirs, plugin dirs) so the the filesystem wouldn't have to be consulted for every file request. Has this ever been tried with Smarty? I started looking at the plugin loader but it looked like it would be a difficult type of feature to graft onto the current engine.

This has been thought about but not much time spent on investigating it. Maybe it is time to re-evaluate the code base and make some fundamental changes to the core, such as pipelining the entire process in a more organized manner. For one, there is way too much going on in the fetch() function IMHO, this should be broken out into a more modular structure. Monte