Re: config vars are now static

--- 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. xo boots __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com