Smarty

[Tom Sommer]

Are we gonna make the embedded-var-in-config-var stuff soon?

PLEEEASSSEEE

[boots]

Hi Tom. You seem so anxious for this, I hope you get it!! But only if it is done right

I was wondering: when should the variables be evaluated? During the template load? I think this would imply no compiling of config files and no caching either.

Hmm. Would an eval operator (something like {@#cnfvar#}) work for ya? Could be a useful operator in other cases, too.

How about a custom resource that reads templates from--config vars (I'm going to go code one right now to see if it works okay).

[Tom Sommer]

What?

No, it would be compiled... without a doubt... why not?

It's just a matter of replacing

"Hello `$nick`, welcome"
with
"Hello ". $this->template_vars['nick'] .", welcome"

or whatever the array with template vars is called

mohrt's got something planned... Thats why I'm asking

consider this:

**** my.conf ****
welcomemsg = "hi `$nick`, welcome"

**** my.php *****
$smarty->config_load('my.conf');
$smarty->assign('nick', 'John');
$smarty->assign('welcome', $smarty->get_config_vars('welcomemsg') );

$smarty->display('my.tpl');

**** my.tpl ****
{#welcomemsg#}
{$welcome}

**** output html ****
Hi John, welcome
Hi John, welcome

[boots]

I see. Makes sense. I guess what I was thinking is that the caching is an issue, but with individual caches available, perhaps that can be worked around. It will be interesting to see how it works out. Still seems like it will make config files more template like which means slower.

Does look like it can be useful. I already have other ways to deal with things like this and I'm sure that Mohrt's choices to handle this will work out well.

Good luck!

[Nagger]

@tom sommer

your example will NOT work, because of the compiling. this is one of the pitfalls with variables in compiled config files.

you have to assign the nick before loading the config_file!
otherwise
"Hello ". $this->template_vars['nick'] .", welcome"
(which will be evaluated at config_load)
leads to "Hello ,welcome".

[Tom Sommer]

[Tom Sommer]

The whole point is that the backtics signify if it is an embedded var, if that is the case, you just have to consider that at compile/display time

[Tom Sommer]

Hmm, I see your point now.... MONTE!!!

[boots]

I just rembered the {eval} plugin. Why doesn't

{eval var=#welcomemsg#}

float your boat? Right, the compilation occurs at runtime--but results are cached!

-- Aside1:
with config_load now out of the core, you can override the default functionality to fetch the config file as a template before it does its assignments. I think that would give you exactly what you are looking for.

-- Aside2:
I remember seeing something on the dev mailing list about work to add sections to templates. That would be bonus in a situation like this. I wonder what the syntax for something like that would be.

{include file="snippets.tpl section="welcomemsg"} ? Looks messy.

Perhaps if a reference to a template could be made we could get something like:

{$snippets|section:welcomemsg}

or even

{%snippets.tpl|section:welcomemsg}

[Tom Sommer]

hmmm eval, we discussed that... not good for performance... not good for compile (I don't use cache)

[Tom Sommer]

my idea would be cool

[boots]

I think my aside 1 will implement your idea transparently. I'm going to get the latest CVS and try it out. If it works ok, I'll post it here.

Hey, I'm now tagged as a Smarty Coder here on the site. Cool!!

[boots]

hmm. two problems already:

1) exposing config_dir to the template engine (I might use a custom resource loader for now)

2) caching: I *think* that the config file will need to know what context it is being called from so that it can create different cache id's for specific templates. hmmmm.

[boots]

While working on an updated conf_load, I realized that it relies on the Config_File.class to load the file from the filesystem in:

[boots]

Well, I got it working somewhat, though I'm having some problems with caching. Do config files have different rules for caching than templates? It doesn't look like they do from what I looked at. hmmm.

Update:
Actually, I think I just figured out my REAL problem: I don't have the ability to save individual php as the compiled conf vars. With my current code, I've disabled compiled config files (ie. the serialized vars array) but the underlying config file is still compiled as a template . It works pretty well, but it can be better. The performance is good. Caching is still not contextual. More work to do, but it is usable.

I JUST noticed the $smarty->config_class attribute which I take I can use to override the default config class handler.

EDIT:

I'll take it a little further if anyone is interested. For myself, I'm not even using config vars at the moment as I've built an experimental hierarchical data loader (templated) which allows things like {$Mydata.myfield.mysubfied} and for which I've already handled pre- serialization.

UPDATE++

I think I got cache_ids and compile_ids supported now which really helps speed things. Still not serializing $_config_vars to file which means there is still a slight compilation penalty compared to normal config_load. Was thinking about adding a new attribute to conf_load (say eval?) to control whether default config loading or templated config loading is performed. Still working on how to best work it in to the code base.