View previous topic :: View next topic |
Author |
Message |
Tom Sommer Administrator
Joined: 16 Apr 2003 Posts: 47 Location: Denmark
|
Posted: Fri Apr 25, 2003 7:54 pm Post subject: Embedded vars in config files |
|
|
Are we gonna make the embedded-var-in-config-var stuff soon?
PLEEEASSSEEE
Last edited by Tom Sommer on Tue Apr 29, 2003 2:04 pm; edited 1 time in total |
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Fri Apr 25, 2003 8:19 pm Post subject: |
|
|
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). |
|
Back to top |
|
Tom Sommer Administrator
Joined: 16 Apr 2003 Posts: 47 Location: Denmark
|
Posted: Fri Apr 25, 2003 8:29 pm Post subject: |
|
|
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 |
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Fri Apr 25, 2003 8:52 pm Post subject: |
|
|
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! |
|
Back to top |
|
Nagger Smarty n00b
Joined: 22 Apr 2003 Posts: 1 Location: Berlin, Germany
|
Posted: Fri Apr 25, 2003 10:16 pm Post subject: |
|
|
@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". |
|
Back to top |
|
Tom Sommer Administrator
Joined: 16 Apr 2003 Posts: 47 Location: Denmark
|
Posted: Fri Apr 25, 2003 10:32 pm Post subject: |
|
|
Nagger wrote: | @tom sommer
you have to assign the nick before loading the config_file! |
No, I don't think so...
The var just has to be there before display() is called |
|
Back to top |
|
Tom Sommer Administrator
Joined: 16 Apr 2003 Posts: 47 Location: Denmark
|
Posted: Fri Apr 25, 2003 10:35 pm Post subject: |
|
|
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 |
|
Back to top |
|
Tom Sommer Administrator
Joined: 16 Apr 2003 Posts: 47 Location: Denmark
|
Posted: Fri Apr 25, 2003 10:47 pm Post subject: |
|
|
Hmm, I see your point now.... MONTE!!! |
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Fri Apr 25, 2003 11:03 pm Post subject: |
|
|
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}
Last edited by boots on Fri Apr 25, 2003 11:14 pm; edited 1 time in total |
|
Back to top |
|
Tom Sommer Administrator
Joined: 16 Apr 2003 Posts: 47 Location: Denmark
|
Posted: Fri Apr 25, 2003 11:07 pm Post subject: |
|
|
hmmm eval, we discussed that... not good for performance... not good for compile (I don't use cache) |
|
Back to top |
|
Tom Sommer Administrator
Joined: 16 Apr 2003 Posts: 47 Location: Denmark
|
Posted: Fri Apr 25, 2003 11:14 pm Post subject: |
|
|
my idea would be cool |
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Fri Apr 25, 2003 11:22 pm Post subject: |
|
|
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!! |
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Fri Apr 25, 2003 11:32 pm Post subject: |
|
|
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. |
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Sat Apr 26, 2003 2:50 am Post subject: |
|
|
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:
Code: | if($_config_vars = array_merge($smarty->_conf_obj->get($_file),
$smarty->_conf_obj->get($_file, $_section))) { ... } |
It would be really handy if we can pass the text of the file instead so that it can be loaded from a custom source. In my case, I want to pass to get() the results of a fetch. In the meantime, I think I will create a new function based on the variable assignment portions of get() and load_file(). |
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Sat Apr 26, 2003 4:59 am Post subject: |
|
|
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. |
|
Back to top |
|
|